DDD领域驱动设计
要理解DDD(Domain-Driven Design，领域驱动设计)，首要就得明白它解决了什么问题。微服务架构解决了高可用、可扩展问题，但随之带来了性能下降，复杂度暴增的问题。DDD分别从战略（业务）和战术（应用）出发，建立领域模型和架构模式，指导微服务的设计和拆分。
一、复杂度的来源及解法
- 高性能
内部:
- 多进程： 为了达到多进程并行运行的目的，采取了分时的方式，即把 CPU 的时间分成很多片段，每个片段只能执行某个进程中的指令
- 进程间通信：管道、消息队列、信号量、共享存储等
- 多线程：任务可以并行，但同时也带来了并发问题和锁
集群：最终决定业务处理性能的还是业务逻辑本身，业务逻辑本身没有发生大的变化下，理论上的性能是有一个上限的，系统拆分能够让性能逼近这个极限，但无法突破这个极限
- 高可用
- 计算高可用：
- 存储高可用：
- 可扩展
- 低成本
- 安全
- 规模
复杂度来源参考：
从0开始学架构-李运华
二、软件架构的演进
微服务的划分一直是软件工程的一个争议点，到底如何拆分，拆分到怎么样的程度一直缺乏一个理论指导。
其实，从服务架构的演进过程可以看到，微服务中基础设施服务、同领域业务服务同样也逐渐聚合收敛了。因此，在大型架构中，类似DDD思想的融入其实早已产生。
三、DDD四层模型
用户界面层：网络协议的转化/统一鉴权/Session 管理/限流配置/前置缓存/异常转换
应用层：业务流程编排（仅编排，不能存在业务逻辑）/ DTO 出入转化
领域层：领域模型/领域服务/仓储和防腐层的接口定义
基础设施层：仓储和防腐层接口实现/存储等基础层能力
简言之，更加抽象技术层次划分，更加聚合资源结构，更加强调用户体验
四、DDD的概念与核心思想
领域模型
DDD的改造，其核心是是如何划定边界，以确定技术架构
划分边界
- 在领域驱动设计的战略设计中，我们采用事件风暴方法梳理业务过程中的用户操作、事件以及外部依赖关系等，从而梳理出领域实体等领域对象。
- 然后，我们根据领域实体之间的业务关联性，形成聚合，并确定聚合中的聚合根、值对象和实体。
- 接着，根据业务及语义边界等因素，将一个或多个聚合划定在一个限界上下文内，形成领域模型。这个过程中，我们建立了领域模型，划定了业务领域的边界，建立了通用语言和限界上下文，确定了领域模型中各个领域对象的关系。这些限界上下文可以作为微服务设计的参考边界，从而确定了应用端的微服务边界。