DDD从小白到入门

DDD进阶篇二

1、 DDD分层架构：有效降低层与层之间的依赖

DDD四层架构：
			
			1、用户接口层（用户界面、Web服务和其他）API、DTO（数据传输对象）：用户接口层负责向用户显示信息和解释用户指令。
				这里的用户可能是：用户、程序、自动化测试和批处理脚本
			
			2、应用层（应用服务）Application Service：应用层是很薄的一层。主要面向用例和流程相关的操作，可以协调多个聚合的服务和领域对象完成服务编排和组合，
				协作完成业务操作。应用层也是微服务之间交互的通道，可以调用其他为服务的应用服务，完成微服务之间的服务组合和编排
				
				应用服务在应用层，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，
				以粗粒度的服务通过API网关向前端发布。
				应用服务还可以进行安全认证、权限校验、事务控制、发送和订阅领域事件等	
				
			3、领域层（聚合实体和值对象、领域服务）Aggregate:(Domain Service、Entity、ValueObject)、MapperXML、Repository ：
				领域层的作用是实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。
				领域层主要体现领域模型的业务能力，用来表达业务概念、业务状态和业务规则。

				领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。
				实体和领域对象在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或值对象）不能实现时，
				领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。			
			
			4、基础层（数据库、时间总线、API网关、缓存、基础服务、第三方工具、其他基础组件）Repository AOP、缓存、总线、网关、第三方工具、文件、其他：
				贯穿所有层，为其他各层提供通用的技术和基础服务，
				比较常见的功能还是提供数据库持久化。

基础服务采用依赖倒置设计，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。
DDD分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。
仓储分为仓储接口和仓储实现两个部分，仓储接口放在领域层中，仓储实现放在基础层。
原来三层架构通过的第三方工具包、驱动、Common、Utility、Config等通用的公共资源类统一放到了基础层。
DDD分层架构的重要原则：每层只能与位于其下方的层发生耦合。
为了服务的可管理，应该采用严格分层架构。在严格分层架构中，领域服务只能被应用服务调用，而应用服务只能被用户接口层调用，
服务是逐层对外封装或组合的，依赖关系清晰，如果领域层中某个服务发生重大变更，只需要逐层通知上层服务就可以了。

2、微服务架构模型：几种常见模型的对比和分析

整洁架构：又名洋葱架构。在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是：
			1、领域模型：实现领域内核心业务逻辑，封装了企业级的业务规则。
				领域模型的主体是实体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合
			2、领域服务：领域服务实现涉及多个实体的复杂业务逻辑
			3、应用服务：实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则，封装和实现了系统所有用例
			4、最外层的用户界面和基础资源：主要提供适配能力，主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。
				被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等
			注：领域模型、领域服务和应用服务一起组成软件核心业务能力

六边形架构：又名端口适配器架构。应用通过端口与外部进行交互。
			核心业务逻辑（应用程序和领域模型）与外部资源（包括APP、Web应用以及数据库资源等）完全隔离，仅通过适配器进行交互，
			解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。

三种微服务架构模型的对比和分析：
三种架构模型的设计思想正是微服务架构高内聚低耦合原则的完美体现，而他们身上闪耀的正是以领域模型为中心的设计思想。
三种架构都考虑了前端需求的变与领域模型的不变，将核心业务逻辑与外部应用、基础资源进行隔离。

从三种架构模型看中台和微服务设计：
		1、中台本质是领域的子域，它可能是核心域、通用域或者支撑域。通常大家认为阿里的中台对应DDD的通用域，
		将通用的公共能力沉淀为中台，对外提供通用共享服务。
		中台建设要聚焦领域模型：中台需要站在全企业的高度考虑能力的共享和复用。
			中台设计时，需要建立中台内所有限界上下文的领域模型，DDD建模过程中会考虑架构演进和功能的重新组合。
			领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界（微服务）划分。
			领域模型的结果会影响到后续的系统模型、架构模型和代码模型，最终影响到微服务的拆分和落地。
		因此，在中台设计中我们首先要聚焦领域模型，将它放在核心位置。	

		2、微服务要有合理的架构分层
			微服务的设计要有分层的思想，让各层各司其职，建立松耦合的层间关系。
			不要把与领域无关的逻辑放在领域层实现，保证领域层的纯洁和领域逻辑的稳定，避免污染领域模型。
			也不要把领域模型的业务逻辑放在应用层，这样或导致应用过于庞大，最终领域模型会失焦。
			如果实在无法避免，我们可以引入防腐层，进行新老系统的适配和转换，过渡期完成后，可以直接将防腐层代码抛弃。

		3、项目级微服务：使用分层架构模型即可。领域模型的核心逻辑在领域层实现，服务的组合和编排在应用层实现，
			通过API网关为前后台提供服务，实现前后端分离。
		4、企业级中台微服务：企业级的业务流程往往是多个中台服务一起协作完成的。
			企业级中台微服务的集成不能像项目级微服务一样，在某一个微服务内完成跨微服务的服务组合和编排。
			但是可以在中台微服务之上增加一层，主要作用就是处理跨中台微服务组合和编排，以及微服务之间的协调，还可以完成不同渠道应用的适配。
			如果将它的业务范围扩大一些，就可以将它做成一个面向不同行业和渠道的服务平台。

			例如 我们可以借用BFF（Backend for Frontends）服务于前端的后端，BFF微服务与其他微服务存在较大的差异，它没有领域模型，也不会有领域层，
			BFF微服务可以承担应用层和用户接口层的主要职能，完成各个中台微服务的服务组合和编排，可以适配不同前端和渠道的要求。
	
	应用和资源的解耦与适配
		传统以数据为中心的设计模式，应用会对数据库、缓存、文件系统等基础资源产生严重依赖。
		在微服务架构中，应用层、领域层和基础层解耦是通过仓储模式，采用倒置的设计方法来实现的。在应用设计中，
		我们会同步考虑和基础资源的代码适配，那么一旦基础设施资源出现变更（比如换数据库），就可以屏蔽资源变更对业务代码的影响，
		切断业务逻辑对基础资源的依赖，最终降低资源变更对应用的影响。

小结：DDD分层架构、整洁结构、六边形架构都是以领域模型为核心，实行分层架构，内部核心业务逻辑与外部应用、资源隔离并解耦。他们是一点一点继承和发展活来的，在大的分层上基本上没有太大的差异，思路基本是一致的，都是以领域模型为中心，加上编排的应用层逻辑，但在分层的内部有一些小的差异，包括外部的适配方式也有差异。直白一点就是业务的归业务，基础的归基础，两者通过一层来适配，具体就是通过接口的方式。
本篇文章讲述了DDD分层架构以及常见微服务架构模型的对比，下节将引入中台的有关知识。