前言
传统数字化转型需要解决的几个问题
1.落后的技术体系在可扩展性和高可用性方面不强。面对突发高频接入的业务场景，无法实现自动弹性伸缩。发展到一定规模后，数据库性能和容量成为业务发展的瓶颈。
2.单片架构将许多功能集成到一个应用程序中。随着时间的推移，这个应用程序变成了一个巨大的怪物。随着人员的更替，很少有人能完全理解这些代码随时间的逻辑关系。有人担心遗留代码，不敢修改之前的代码，更喜欢复制一个代码再修改，导致应用越来越复杂，最终陷入恶性循环。单体也具有较高的模块耦合性，灵活扩展资源利用率低。
3.逆向研发；以及操作和维护能力。云平台和自动化运维工具对单个应用的生态支持有限，部署和运维相对复杂。应用中的问题基本靠人肉调查，很难快速定位运维和研发；D.
4.4的重复构造。IT能力传统企业已经建立了单一核心系统。为了在移动互联网中发展业务，建立了一套移动互联网应用，出现了一些业务同质化的问题。为了解决这个问题，需要提高技术能力，重构业务模型，实现企业级业务的能力重用。
微服务虽好，但只是手段，不是目的。微服务是解决业务和应用扩展能力，也是更好的上云方式。微服务的实现需要一定的前提条件。随着技术能力的提升，传统应用和移动应用有了统一的基础；只有应用统一了，业务模型才能统一；只有统一业务模式，才能实现业务能力的共享和复用，企业才有实施中台战略的技术基础。
为什么会面临单一架构的问题？
团队小的时候，单体的开发效率最高。当时，团队的技术能力不足，研发；d人员对服务器资金不足重视不够，业务发展不被允许，业务需要快速实现功能，没有太多时间设计系统的可扩展性和高可用性。所以单体架构可能是很多团队不得不面对的问题。企业发展的同时，单体向微服务的迁移也是他们不得不面对的问题。
知道中泰吗
ThoughtWorks对中间平台的定义：“中间平台是企业级能力重用平台”。中间办公室本质上是企业的商业模式。如何在中间平台落地，微服务架构是目前公认的最佳实践。在中间平台落地时，会面临如何拆分和设计微服务的问题。有没有好的方法来指导微服务的拆分和设计？这就是DDD(领域驱动设计)。DDD包括两个阶段：战略设计和战术设计。通过战略设计，完成中台之间的业务边界划分和领域建模，然后将领域模型作为战术设计的输入，完成微服务设计。
阿里对前台、中台和后台职责的定位，前台主要面向客户和终端卖家，实现营销推广和交易转换。中办主要面向运营商，提供运营支持。后台主要为后台管理人员，实现流程审核、内部管理和后勤保障，如采购、人力、财务、OA等系统。企业级能力往往是前台、中台、后台协同能力的体现。如果将业务中办比作陆军、火箭军、空军等专业服务，主要发挥单个服务的战术专业能力，那么前台就是作战力量，将根据前沿战场的实时作战需求，快速组合调度不同功能业务的中办能力，实现不同业务板块能力的融合，形成强大的组合
DDD由战略设计和战术设计两部分组成，分别从不同角度完成领域建模和微服务的划分和设计。战略设计是从业务的角度划分业务的领域边界，基于业务上下文的公共语言和语义边界建立边界上下文，构建领域模型。边界上下文可以作为微服务拆分和设计的边界。
战术设计从技术角度着眼于领域模型的技术实现，根据领域模型完成微服务的开发和落地。在战术设计中，会有聚合、聚合根、实体、价值对象、域服务、域时间、应用服务、仓库等域对象。这些领域对象将以代码的形式映射到微服务，完成设计和系统落地。
DDD战略设计中的领域建模是一个从发散到收敛的过程，通常采用事件风暴工作法。Storm是一个团队活动，其中领域专家和项目团队通过头脑风暴列出领域中的所有领域事件，然后为每个事件标记导致该事件的命令，然后为每个事件标记该命令的发起者角色。
基于事件风暴的领域建模关键流程包括：产品视觉分析(可选)、场景分析、领域建模、微服务拆分和设计。原则上，边界上下文中的域模型可以被设计为微服务。而领域建模只考虑业务因素，不考虑微服务落地的技术、团队、运行环境等非业务因素。因此，它只能作为微服务拆分的一个非常重要的基础，而不是唯一的基础。建立一个边界清晰的领域模型是我们最关键的目标。
DDD的核心目的是为“高内聚、低耦合”提供一种可行的方法。
DDD、中间平台和微服务的关系
这里有个设计经验，在设计过程中我们可以用一些表格来记录事件风暴和微服务设计过程中产生的领域对象与属性。
需要强调一次：DDD分析和设计过程中的每个环节，都需要保证界限上下文内通用语言的统一和正确性。在代码模型设计的时候要建立领域对象和代码对象的一一映射，从而保证业务模型和系统模型一致，实现业务语言和代码语言的统一。
子域和界限上下文的关系？大多数情况下是一对一或一对多的映射关系。有时候业务领域非常庞大，不太方便使用时间风暴对整个领域构建领域模型，所以在领域建模前，我们先根据业务流程边界或功能集合等要素，将庞大领域分解为若干个合适的子域，然后在根据属性划分为核心子域、通用子域、支撑子域，然后再对这些子域内开展事件风暴，划分界限上下文
实体和值对象在代码模型中，实体的表现形式是实体类，这个类包含了实体的属性和方法，通过这些方法实现实体自身的业务行为和业务逻辑，这些实体通常采用充血模型，跨多个实体的领域逻辑则在领域服务中实现。贫血模型中领域对象大多只有setter和getter方法，业务逻辑统一放在业务逻辑层实现，而不是领域对象中实现。
实体以领域对象（DO）的形式存在，每个实体对象都有唯一的ID，我们可以对一个实体对象多次修改，修改后的实体数据和原来的数据可能会不大相同，但是由于拥有相同的ID，他们仍然是一个实体。比如商品是商品界限上下文的一个实体，通过唯一的商品ID来标示。不管这个商品的数据如何变化，商品的ID一直保持不变，所以它始终是同一个商品。
实体的数据库形态，与传统数据库模型设计优先不同，DDD是先构建领域模型，通过场景分析找出实体对象和行为，再将实体对象映射到数据持久对象。一个实体可以对应0个、1个或多个数据库持久化对象。如何解决一对多或多对一场景？
值对象本质是个属性集合，是不可变的，它没有ID，它只是有数据初始化操作和有限的不涉及修改数据的行为，基本不包含业务逻辑。
聚合与聚合根
实体和值对象都是个体化的业务对象，他们表现出来的是个体的行为和能力。在领域模型中，我们需要一个这样的组织，将这些紧密关联的个体对象聚集在一起，按照组织内统一的业务规则共同完成特定的业务功能，因此就有了聚合的概念。聚合内数据的修改必须由聚合根统一组织，以确保每次数据修改都是按照聚合内统一的业务规则来完成。过去，在传统数据模型中每个实体都是对等的，在业务逻辑实现时，可以随意找到实体或数据库表完成数据修改，但这类操作在DDD的聚合内是不被允许的。
调用关系：
聚合内的实体以充血模型实现自身的业务逻辑跨多个实体的业务逻辑通过领域服务实现跨多个聚合的业务逻辑的组合和编排，是通过应用服务来实现的判断一个实体是否是聚合根？是否有独立的生命周期是否有全局唯一ID是否可以创建或修改其他对象是否有专门的模块来管理这个实体怎么理解聚合根管理功能？
聚合设计原则
聚合是拆分微服务最小业务单元设计小聚合通过唯一ID引用其他聚合在边界之外使用最终一致性。在聚合内采用数据强一致性，在聚合之间采用数据最终一致性。这时因为DDD强调子一次事务中，最多只能修改一个聚合的数据。如果涉及多个聚合数据修改，那么应采用领域事件驱动机制。怎么理解边界之外？是界限上下文？还是理解成聚合？通过应用层实现跨聚合的服务调用。聚合根在聚合内对实体和值对象通过对象引用的方式进行组织和协调，聚合与聚合之间只能通过聚合根ID引用的方式，实现聚合之间的访问和协同。仓储模式就是用来隔离业务实现逻辑与基础层资源实现逻辑，降低它们之间的耦合和相互影响而产生的。仓库模式包含仓储接口和仓储实现，仓储接口面向领域层提供基础层数据处理相关的访问接口，仓储实现完成仓储接口对应的数据持久化相关的逻辑处理。
领域事件：解耦微服务的关键
到底是将领域事件直接发布到时间总线、消息中间件、或者通过CDC再转发到消息中间件，可根据业务场景选择因为关键数据不能丢失或者需要数据对账，所以事件发布之前需要持久化到数据库事件表中。
DDD分层架构
微服务目录结构
interfaces目录下面有assembler、dto、facade
assembler实现DTO和DO领域对象之间的相互转换和数据交换，同dto同时出现dto是前端应用数据传输的载体，前端需要的数据格式或前端传输过来的数据格式。facade封装应用服务，将用户请求委派到一个或多个应用服务进行处理。application目录有event、serviceevent主要是publish和subscribeservice是应用服务，
对于多表关联的复杂查询，由于这种复杂查询不需要有领域逻辑和业务规则约束，因此不建议将这类复杂查询放在领域层的领域模型中，可以通过应用层的应用服务采用传统多表关联的SQL查询方式，也可以采用CQRS读写分离方式完成数据查询操作。
为了实现微服务内聚合的解耦，原则上我们应该尽量避免聚合之间的领域服务直接调用和聚合之间的数据库表关联。聚合之间的服务调用和数据交互，可通过应用服务完成。
domian目录下面的leave、person、rule都是聚合
领域事件订阅建议放到应用层event,领域事件发布相关代码放到领域层和应用层都是可以的。
工厂类（factory）放到领域层聚合的service目录下，仓储相关代码放到领域层聚合的repository目录结构下。