软件架构演进过程
现在微服务的拆分十分的困难，其根本原因是不知道业务和微服务的边界如何拆分。
领域驱动就是一套方法论，通过领域驱动设计方法论来定义领域模型，从而确定业务边界和应用边界，保证业务模型和代码模型的一致性。
领域驱动设计是处理复杂领域的设计思想，把业务复杂性和技术复杂性分离，运用业务概念构建领域模型来控制业务复杂度。领域驱动不是架构，而是一种架构设计的方法论，通过边界划分把复杂的业务简单化，帮我们设计出清晰的领域和应用边界，可以容易的实现架构的演进。
领域驱动包括战略设计和战术设计两个部分
- 战略设计是从业务视角出发，建立领域模型。划分领域边界，建立通用语言限界上下文，限界上下文可以作为微服务划分的边界。
- 战术设计是从技术的视角出发，通过领域模型，完成软件的落地。包括：聚合根、实体、值对象等的设计与实现。
怎么划定领域模型和微服务的边界
- 通过事件风暴梳理业务中用户的操作、事件以及外部的依赖关系等，根据这些要素梳理出领域实体等领域对象。
- 通过实体之间的业务关系，将业务紧密相连的放在一起，形成聚合，并且找出其中最核心的部分，形成聚合根，在这个图中，聚合之间的边界是第一层边界，他们在同一个微服务中运行，这个边界是逻辑边界，所以用虚线表示。
- 通过业务或者语义边界，把一个或者多个聚合放到一个限界上下文中，这样就形成了领域模型。在这一层中，可能就是微服务划分的边界，运行在不同的应用中，所以用实线表示。
业务模型向微服务落地的过程中，是战略设计向战术设计实施的过程。我们需要把领域模型和代码模型建立一一映射的关系，将业务架构和系统架构进行绑定。
DDD与微服务的关系
DDD是一种架构设计方法论，微服务是一种架构风格，他们关注的点不一样
DDD主要关注：从业务领域视角划分领域边界，构建通用语言进行沟通，通过业务抽象，构建领域模型，实现业务架构和系统架构的统一。
微服务主要关注：微服务的独立开发、测试、运维、部署等。