❝「尺有所短，寸有所长；不忘初心，方得始终。」
❞
一、软件架构的演进史
软件架构大致经历了从单机架构，集中式架构，分布式微服架构，程序的层次图如下所示。
「单机架构」
Servlet+jsp的时代
「属于面向过程的设计思想」，系统采用C/S架构，仅包含客户端UI层和数据库两层，围绕数据库驱动设计和开发。
「集中式架构」
SSM、SSH的时代
「属于面向对象的设计思想」，采用经典的三层架构或者 SOA 架构，系统包括业务接口层、业务逻辑层和数据库层。随着业务的增加和时间的推移这种架构会变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。
「分布式微服务架构」
SpringCloud、SpringBoot的时代 「分布式微服务架构实现业务和应用之间的解耦，提供了负载均衡的能力，解决集中式单体应用扩展性和弹性伸缩能力不足的问题与高并发的需求」
二、微服务拆分和设计的困境
微服务的特点就是一个【微】字，它可以「提高系统的扩展性、弹性伸缩能力、小规模团队的敏捷开发」。但是由此也衍生出一系列的问题：
微服务的粒度应该多大？ 微服务应该如何拆分和设计？ 微服务的边界应该在哪里？ 
产生这些问题的根本原因：「不知道业务或者微服务的边界在什么地方。「这些问题如果没有在前期做好设计，后期就会」导致微服务拆分过度，项目复杂度过高，甚至无法上线和运维」。
基于此：基于DDD的微服务设计就很有必要了，「DDD 核心思想就是通过领域驱动设计得方法论定义领域模型，确定业务和应用边界，保证业务模型与代码模型的一致性。」
三、DDD为什么适合微服务
DDD的设计理念恰好弥补了微服务拆分和设计的困境，「通过战略设计和战术设计分离技术实现的复杂性，围绕业务构建领域模型划定边界。通过边界划分将复杂业务领域简单化，设计出清晰的领域和应用边界，实现服务的内部高内聚，外部低耦合，可持续演进的微服务架构。」
「战略设计」
「从业务视角出发，划分业务的领域边界，建立通用语言和限界上下文（业务边界：微服务拆分和设计的边界），构建领域模型。」
实现领域边界划分的重要方法是【「事件风暴」】
「构建领域模型和划分微服务的边界」
在事件风暴中根据业务场景分析，梳理用户操作、领域事件以及外部依赖等，分析业务对象产生的操作或行为等实体「梳理出领域对象」
根据业务实体之间的业务关联性，「确定聚合根、值对象和实体。将业务紧密相关的，相互依赖的实体组合形成聚合。」
❝
聚合是第一层边界，属于同一个微服务中。
❞根据业务语义环境及上下文边界等，将一个或者多个聚合划定在一个限界上下文内，构建领域模型。
❝
限界上下文是第二层边界，属于微服务的物理边界。
❞
「战术设计」
「从技术视角出发，按照领域模型完成微服务的技术落地。」
「在战术设计中会将【聚合、聚合根、实体、值对象、领域服务、领域事件、应用服务和仓储】等领域对象映射到微服务的实际代码落地中，完成微服务设计和系统落地。」
领域模型中的领域对象跟代码模型中的对象对应，将业务架构和系统架构进行绑定，当业务架构和领域模型调整的时候，系统架构也会随之调整；
「微服务和DDD之间的映射」
