DDD从小白到入门

DDD进阶篇三

1、 中台：将通用的公共能力独立为共享平台，是企业级能力复用平台

阿里对中台的定义：中台是一个基础的理念架构，我们要把所有的基础服务用中台的思路建设，进行联通，共同支持上端业务。
业务中台更多的是支持在线业务，数据中台提供了数据处理能力和很多的数据产品给所有业务方去用。业务中台、数据中台、算法中台等等一起提供对上层业务的支撑。前台：主要面向客户以及终端销售者，实现营销推广以及交易转化。中台后的前台建设要有一套综合考虑业务边界、流程和平台的整体解决方案，以实现各不同中台前端操作、流程和界面的联通、融合。不管后端有多少个中台，前端用户感受到的就是只有一个前台。前端页面可以很自然地融合到不同的终端和渠道应用核心业务链路中，实现前端页面、流程和功能复用。 中台：主要面向运营人员，完成运营支撑，业务中台的建设可采用领域驱动设计方法，通过领域建模，将可复用的公共能力从各个单体剥离，沉淀并组合，采用微服务架构模式，建设成为可共享的通用能力平台。 业务中台向前台、第三方和其他中台提供API服务，实现通用能力和核心能力的复用

数据中台的目标是打通数据孤岛，实现业务融合和创新，包括三大职能：
			1、完成企业全域数据的采集和存储，实现各不同业务类别中台数据的汇总和集中管理。
			2、按照标准的数据规范或数据模型，将数据按照不同主题域或场景进行加工和处理，形成面向不同主题和场景的数据应用，比如客户视图、代理人视图、渠道视图、机构视图等不同数据体系。
			3、建立业务需求驱动的数据体系，基于各个维度的数据，深度萃取数据价值，支持业务和商业模式的创新。
	       
数据中台的建设分为三步：
			1、实现各中台业务数据的汇集，解决数据孤岛和初级数据共享问题。
			2、实现企业级实时或非实时全维度数据的深度融合、加工和共享
			3、萃取数据价值，支持业务创新，加速从数据转换为业务价值的过程。

后台：主要面向后台管理人员，实现流程审批、内部管理以及后勤支撑，比如采购、人力、财务和OA(Office Automation)等系统。前台通过页面和流程共享实现不同渠道应用之间的前台融合，中台通过API实现服务共享。而前台、业务中台和数据中台的融合可以实现传统应用与互联网应用的融合，从而解决“后端双核心，前端两张皮”（各做各的事）的问题。能力复用了，前台流程和数据融合了，才能更好地支持业务的融合和商业模式的创新。

2、DDD、中台和微服务的协作

DDD和微服务来源于西方，中台诞生于阿里。中台是抽象出来的用户模型，微服务是业务模型的系统实现，DDD作为方法论可以指导中台业务建模和微服务建设，三者相辅相成。
DDD的本质：DDD会按照一定的规则将业务领域进行细分，领域细分到一定的程度后，DDD会将问题范围限定在特定的边界内，并在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。通过领域划分和进一步的子域划分，我们就可以区分不同子域在企业内的功能属性和重要性，进而采取不同的资源投入和建设策略。
中台的本质：提炼各个业务板块的共同需求，进行业务和系统抽象，形成通用的可复用的业务模型，打造成组件化产品，供前台部门使用。前台要做什么业务，需要什么资源，可以直接找中台，不需要每次都去改动自己的底层。

	中台建模过程：中台业务抽象的过程就是业务建模的过程，对用DDD的战略设计。系统抽象的过程就是微服务的建设过程，对应DDD的战术设计。
		1、按照业务流程（通常适用于核心域）或者功能属性、集合（通常适用于通用域或支撑域），将业务域细分为多个中台，再根据功能属性或重要性归类到核心中台或通用中台。
			核心中台设计时要考虑核心竞争力，通用中台要站在企业高度考虑共享和复用能力。
		2、选取中台。根据用例、业务场景或用户旅程完成事件风暴，找出实体、聚合和限界上下文。一次进行领域分解，建立领域模型。这一步只需要初步确定主领域模型就可以了。
		3、以主领域模型为基础，扫描其他中台模型，检查并确定是否存在重复或者需要重组的领域对象、功能，提炼并重构主领域模型，完成最终设计。
		4、选择其他主领域模型重复第三步，直到所有主领域模型完成对比和重构。
		5、基于领域模型完成微服务设计，完成系统落地。

以保险领域为例：完成领域建模后，里面的数据我们就可以填上了，这里选取通用中台的用户、客户和订单三个中台来做示例。客户中台提炼出两个领域模型：客户信息和客户信息模型。用户中台提炼出了三个领域模型：用户管理、登录认证和权限模型。订单中台提炼出了订单模型。
DDD中台设计的过程：业务领域分解为中台，对中台归类，完成领域建模，建立中台业务模型。DDD战术设计是第五步，领域模型映射为微服务，完成中台建设。

三个典型问题
			1、关于领域可以划分为核心域、通用域和支撑域，以及子域和限界上下文关系的话题，还是是否有边界划分的量化标准？
				对于领域问题来说，可以理解为，对一个问题不断地划分，知道划分为我们熟悉的、能够快速处理的小问题。然后再对小问题的处理排列一个优先级。
				在领域细分到一定程度后，我们就可以对这个子域进行事件风暴，为这个子域划分限界上下文，建立领域模型，然后就可以基于领域模型进行微服务设计了。
				
			2、关于聚合设计的问题？领域层与基础层为什么要依赖倒置（DIP）（Dependence Inversion Principle依赖倒置原则）？	
				聚合主要实现核心业务逻辑，里面有很多的领域对象，这些领域对象之间需要通过聚合根进行统一的管理，以确保数据的一致性。
					聚合设计时，会用到两个重要的设计模式：工厂模式和仓储模式（Factory、Repository）
						工厂模式来封装复杂对象的创建过程
						仓储模式实现聚合内数据的持久化，实现了应用逻辑与基础资源的解耦，也就实现了依赖倒置。
			3、领域事件采用消息异步机制，发布方和订阅方数据如何保证一致性？微服务内聚合之间领域事件是否一定要用事件总线？
				在领域事件设计中，为解耦服务，微服务之间数据采用最终一致性原则。由于发布方式在消息总线发布消息之后，并不关心数据是否送达，或者送达后订阅方是否正常处理，
				因此有些技术人员会担心发布方和订阅方数据一致性的问题。
				
				在对数据一致性比较高的业务场景中，是有相关的设计考虑的。也就是发送方和订阅方的事件数据都必须落库，发送方除了保存业务数据以外，在往消息中间件发布消息之前，
				会先将要发布的消息写入本地库。而接受方在处理消息之前，需要先将收到的消息写入本地库。然后采用定期对发布方和订阅方的事件数据对账的操作，识别出不一致的数据。
				如果数据出现异常或不一致的情况，可以启动定时程序再次发送，必要时可以转人工操作处理。
				
				关于事件总线的问题。由于微服务内的逻辑都在一个进程内，后端数据库也是一个，微服务内的事务相比微服务之间会好控制一些。
				在处理微服务内的领域事件，会增加开发的复杂度。在不会出现导致聚合之间数据不一致的情况，就可以不使用事件总线，另外，通过应用服务也可以实现聚合之间的服务和数据协调。

本篇文章介绍了中台的相关概念，下节将进入实战部分。