系统设计与架构，与系统的业务类型关联还是很大的，比如传统的业务系统主
要关注的是领域建模设计，高并发、高可用、数据一致性等系统，在设计的时
候会与业务系统有较大的差别，所以这里针对不同类型的系统，来简单介绍一
下设计的时候面临的一些难点与解决方案。
背景常规业务系统设计关键——领域模型
业务系统设计的关键是在于如何定义系统的模型以及模型之间的关系，其中主
要是领域模型的定义，当我们在模型确定之后，模型之间的关系也会随之明确。
模型设计可以参考领域模型的经典书籍《Domain-Driven Design》一书，通
过这个基本可以对领域定义、防腐层、贫血模型等概念有一个较为清晰的认识
了。
单个应用内的领域模型系统也需要注意领域分层，作为开发大家是不是见过、
重 构 过 很 多 Controller-Service-DAO 样 式 的 代 码 分 层 设 计 ？ 往 往 在 在 做 重
构的时候会令人吐血。
设计较好的领域设计这里给一个分层建议：
接口层 Interface
主要负责与外部系统进行交互&通信，比如一些 dubbo 服务、Restful API、
RMI 等，这一层主要包括 Facade、DTO 还有一些 Assembler。
应用层 Application
这 一 层 包 含 的 主 要 组 件 就 是 Service 服 务 ， 但 是 要 特 别 注 意 ， 这 一 层 的
Service 不是简单的 DAO 层的包装，在领域驱动设计的架构里面，Service 层
只是一层很“薄”的一层，它内部并不实现任何逻辑，只是负责协调和转发、
委派业务动作给更下层的领域层。
领域层 Domain
Domain 层是 领域模型 系统的 核心，负 责维护面 向对象 的领域模 型，几 乎全
部的业务逻辑都会在这一层实现。内部主要包含 Entity（实体）、ValueObject
（值 对象） 、Domain Event（领 域事件 ）和 Repository（仓 储）等 多种重
要的领域组件。
基础设施层 Infrastructure
它主要为 Interfaces、Application 和 Domain 三层提供支撑。所有与具体
平 台 、 框 架 相 关 的 实 现 会 在 Infrastructure 中 提 供 ， 避 免 三 层 特 别 是
Domain 层掺杂 进这些实现 ，从而“污染 ”领域模 型。Infrastructure 中最
常见的一类设施是对象持久化的具体实现。
高并发系统设计
在面试中是不是经常被问到一个问题：如果你系统的流量增加 N 倍你要怎么
重新设计你的系统？这个高并发的问题可以从各个层面去解，比如
代码层面
锁优化（采用无锁数据结构），主要是 concurrent 包下面的关于 AQS
锁的一些内容
数据库缓存设计（降低数据库并发争抢压力），这里又会有缓存、DB 数
据不一致的问题，在实际使用中，高并发系统和数据一致性系统采用的策