软件架构演进过程
现在微服务的拆分十分的困难，其根本原因是不知道业务和微服务的边界如何拆分。
领域驱动就是一套方法论，通过领域驱动设计方法论来定义领域模型，从而确定业务边界和应用边界，保证业务模型和代码模型的一致性。
领域驱动设计是处理复杂领域的设计思想，把业务复杂性和技术复杂性分离，运用业务概念构建领域模型来控制业务复杂度。领域驱动不是架构，而是一种架构设计的方法论，通过边界划分把复杂的业务简单化，帮我们设计出清晰的领域和应用边界，可以容易的实现架构的演进。
领域驱动包括战略设计和战术设计两个部分
- 战略设计是从业务视角出发，建立领域模型。划分领域边界，建立通用语言限界上下文，限界上下文可以作为微服务划分的边界。
- 战术设计是从技术的视角出发，通过领域模型，完成软件的落地。包括：聚合根、实体、值对象等的设计与实现。
怎么划定领域模型和微服务的边界
- 通过事件风暴梳理业务中用户的操作、事件以及外部的依赖关系等，根据这些要素梳理出领域实体等领域对象。
- 通过实体之间的业务关系，将业务紧密相连的放在一起，形成聚合，并且找出其中最核心的部分，形成聚合根，在这个图中，聚合之间的边界是第一层边界，他们在同一个微服务中运行，这个边界是逻辑边界，所以用虚线表示。
- 通过业务或者语义边界，把一个或者多个聚合放到一个限界上下文中，这样就形成了领域模型。在这一层中，可能就是微服务划分的边界，运行在不同的应用中，所以用实线表示。
业务模型向微服务落地的过程中，是战略设计向战术设计实施的过程。我们需要把领域模型和代码模型建立一一映射的关系，将业务架构和系统架构进行绑定。
DDD与微服务的关系
DDD是一种架构设计方法论，微服务是一种架构风格，他们关注的点不一样
DDD主要关注：从业务领域视角划分领域边界，构建通用语言进行沟通，通过业务抽象，构建领域模型，实现业务架构和系统架构的统一。
微服务主要关注：微服务的独立开发、测试、运维、部署等。
标签：架构,边界,模型,业务,领域,设计,驱动,DDD 来源： https://blog.csdn.net/qq_44797267/article/details/120301795
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。