如何基于DDD构建微服务架构

微服务构建本质上是软件构建过程中长期演进积累的一系列理念、架构原则、工具和最佳实践。
领域驱动设计的软件思想体系和方法论可以用于指导微服务建模、微服务划分、微服务架构设计等相关工作，它可以促使技术人员与领域专家达成共识，构建领域边界合理、具备明确界限上下文、关注点分离、独立自治的微服务。
1
领域驱动设计概述
领域驱动设计（DomainDrivenDesign）概念的兴起可以追溯到1986年，《人月神话》的作者Brooks提出软件的本质复杂性（EssentialComplexity）存在于复杂的业务领域中，技术仅仅是辅助工具，它解决的问题是帮助业务领域从现实问题映射转换成软件实现。
领域驱动设计在战略设计层面，从业务视角出发使技术人员专注于问题域，从领域专家那里获得领域见解，通过模块划分建立领域服务边界，通过界限上下文明确服务的职责。
领域驱动设计在战术设计层面，从技术的视角出发，提炼有效的业务模型，实施领域建模、架构设计完成软件的落地。
领域驱动设计通过隔离业务与技术的复杂性，成为程式化、标准化的软件架构设计范式。
软件复杂度的来源
业务的复杂性：业务的复杂性体现在业务流程不清晰、业务参与人员多、业务与技术耦合等方面。在业务的早期阶段，为了快速满足功能需求容易形成面条式的代码风格，这样的代码风格会导致软件模块膨胀、开发效率降低、功能扩展步伐放缓、业务模型与代码脱节等。
技术的复杂性：技术的复杂性来源于对项目的质量属性需求，诸如系统的性能、客户体验、服务高可用性等。为解决服务的响应延迟、吞吐、安全等问题，我们会引入缓存、消息队列、第三方模块组件，而这些技术的整合给系统引入了额外的复杂性和技术挑战。
质量属性需求：系统非功能（也叫非行为）部分的需求。
领域驱动解决之道
解决这种软件构建中面临的复杂性问题，我们需要从领域开始着手，与业务专家一起获得领域见解，促使软件利益干系方在领域内建立通用语言。技术人员通过建模的手段提炼出事物的本质，以便更好地指导应用系统的构建和规划。
领域驱动设计中包含了大量成熟的理论、概念、模式和架构，它包含一套解决复杂领域模型的软件架构方法，思想是围绕业务模型来连接和实现核心业务概念。
领域驱动设计可以让业务和技术的变化产生的不可预知因素互相分离，将人员变动、团队规模、协作沟通等外界因素变化对产品和项目的影响封装在一个可控的容器和框架下，从而解决软件面临的复杂性问题，如下图所示。

文章图片
事务脚本模式与领域建模模式
事务脚本模式：事物脚本模式常见于单体应用中，它将所有逻辑全部组织在一个单一过程方法中，从数据库的调用到不同业务逻辑、策略的执行全部集成在一个大的方法块中。它的好处是简单、容易实现，它的缺点是没有自己的状态，也无法扩展，容易将服务组件与数据存储模型之间的刚性依赖引入业务逻辑中。
领域建模模式：领域建模模式将业务逻辑转移到了领域对象（DomainObject）中，每个领域对象完成属于自己的业务行为。同时数据存储层的逻辑也变得相对简单，数据库不再参与领域模型的业务逻辑，而是回归数据“持久化”的本质。
使用领域模式可以提升系统的内聚性和可重用性，通过不同类之间的协同完成所有功能。另外，多态的模式也让扩展新的策略更加方便，业务语义更加通用、显性化。领域建模过程遵循“SOLID”原则并实现业务域的逻辑解决方案。