DDD领域驱动设计的项目实践
DDD的概念众所周知，各个文章中的基本概念也都大同小异。这里就不再累述了。DDD最大的好处是使用 领域通用语言（UBIQUITOUS LANGUAGE） 将原先晦涩难懂的业务通过领域概念清晰的显性化表达出来。写这篇文章的目的在于学习怎么使用DDD来降低应用的复杂度，增加框架的可扩展性。本文主要阐述了我在项目中的思考过程和架构实现。 我们从以下一些方面进行些讨论以帮助我们完成DDD的具体实践。 分层最大的意义是在架构的层面上来进行职责的拆分，分离关注点，每一层都确定独立的职责，分层内部保持高度内聚性，让每一层只解决该层关注的问题，从而将复杂的问题简化，它们 只对下层进行依赖 ，实现高内聚低耦合、职责分离的思想。 应用层代表。 那么应用层代表什么，就是代表系统；所以， 我们要明白人与系统的关系；人使用系统，系统提供外部功能，系统内部有领域模型； 这个问题，DDD通过DCI架构（Data、Context和Interactive三层架构），显式的用role对行为进行建模，同时让role在context中对应的领域对象进行绑定(cast)来解决。 待扩展....... 由于DDD分层架构这种向下依赖的模式使得整个框架对于Infrastructure层过度依赖，这不是我们所期望的，我们希望能在Application和Domain层更多的决定领域的功能和流程。所以根据DIP（依赖倒置）原则， 高层模块和低层模块都应该依赖于抽象，为了让模型的逻辑定义更为内聚，我们可以把抽象放在上层（Application、Domain），Infrastructure提供实现。 例如在现在的项目中，我们在Domain层中定义IRepository、ISender、IListener等行为接口，在Frameworks and Drivers层(The Clean Architecture)实现接口，通过注入的方式提供给Domain层。这样能够使依赖的核心层更加内聚，同时对外层的扩展预留出了足够的空间。 （同样的操作我们还尝试的用在对领域层中，将领域对象抽象化，使领域服务依赖于领域对象的抽象，将真正的的领域对象交给更外层去实现，来满足我们架构对于相似业务的扩张能力。但这种做法是极具风险的，不同业务的差异化和领域对象抽象的能力都是极难把握的。总的来说，我们所期望的方向是：1.抽象能够涵盖所有业务。2.业务的差异化只在抽象的实现层被应用。只有满足以上2点，我们的想法才有可能被实现。） 聊完了高低层模块的依赖，我们再来聊下同层之间的依赖。 分层架构的一个重要原则是 每层只能与位于其下方的层发生耦合 ，有些书中还有严格分层架构和松散分层架构两种区分。两者的区别在于能否对非直接下层发生耦合。但有一点是相同的，同分层之间的耦合都是不被允许的。但问题是有些时候，实际情况使它并不是容易被实现的。 例如在我们的项目中，为了满足高吞吐的业务需求，我们选用了Actor模型和AKKA多线程框架来构建我们的架构。这种响应式的异步模式上层无法及时获得下层的反馈，这使上层对下层的协调、分配变得异常艰难。所以我们需要在不同的分层中都创建Actor进行交互，通过对sender的回件来进行解耦。（TODO:图） Actor模型对于DDD的使用还是有很多帮助的，他们都有相同的对象理念，同时，这种响应式架构使领域事件到其他的边界上下文或微服务变得更容易。 经过一些分层、抽象，The Clean Architecture是我们项目期望的目标。 关于整洁架构...等有时间再写了... The Clean Code Blog by Robert C. Martin (Uncle Bob) 领域建模是整个DDD中比较核心的步骤，大部分DDD的工程都是基于领域建模展开的。这里同样不再对实体，值对象等做过多的名词解释，只来记录一次领域建模的过程。 这是一个关于交易平台报价行情系统的部分需求： 1.交易员提交报价 2.交易员选择[群组]提交报价 3.交易核心处理报价 4.交易核心下发[报价报告] 5.交易核心下发[报价行情消息] 6.行情系统订阅交易核心相关消息 7.行情系统收到[全市场][报价报告]，开始计算报价行情： a.根据[报价报告][计算]出[公有报价行情]。b.根据[公有报价行情][聚合]出[公有聚合报价行情]。c.根据[公有报价行情]为[机构]生成[私有报价行情]。d.根据[私有报价行情][聚合]出[私有聚合报价行情]。 8.行情系统收到[群组][报价报告]，开始计算报价行情： a.根据[报价报告]为[群组]包含的[机构][计算]出[私有报价行情]。b.根据[私有报价行情][聚合]出[私有聚合报价行情]。 9.行情系统收到[公有报价行情消息]，开始计算报价行情： a.将[公有报价行情消息][转化]成[公有报价行情]。b.根据[公有报价行情][聚合]出[公有聚合报价行情]。 10.行情系统收到[私有报价行情消息]，开始计算报价行情： a.将[私有报价行情消息][转化]成[私有报价行情]。b.根据[私有报价行情][聚合]出[私有聚合报价行情]。 第一步：分析需求，定义关键类，描述业务流程 1.从需求中抽象出我们所关心的类 Book:报价簿，报价行情形象话的表现 Page:报价簿中记录内容的抽象类 Institution:......... 2.建立类的大致内容、行为和关系 上图只是对类的简单定义，项目中最后落地一定不可能如此简单，需要进行反复的细化工作。 3.描述大致的业务活动图 第二步：划分主要构成 我们必须在这步中识别出模型中的实体、值对象，定义出核心域、子域并理清关系，划分应用层和服务层，确定限界上下文边界。 本需求寻找核心有两种方向，一种以 行情计算和聚合 为核心，机构、群组等作为独立子域；一种以 行情拥有对象（全市场、机构） 为核心，行情计算、聚合作为支撑子域；第一种偏向横向分层，第二种偏向纵向分层。按实际情况，我们选择了第二种方式，围绕Owner(全市场和机构)展开它们的行情计算、价格预警、价格变化、单机构等等。同时，上面的类图、流程图都需要调整，使依赖尽量向核心（Owner）偏移。 核心域：Owner。生成报价行情的对象，报价行情的所有者。 子域：报价簿子域、资产子域、群组子域、预警子域、监控子域、报价明细子域。 实体：机构、群组、全市场、报价单、报价簿、报价明细、资产信息。 值对象：报价簿规则、报价簿ID。 领域服务：机构服务、群组服务、行情计算服务、行情聚合服务、报价预处理服务、仓库服务。 第三步：聚合 根据前面的识别出来的各类对象初步构造出模型。 待续.... Actor是Actor.class模型的核心，怎样在DDD的架构中使用Actor？ Actor的能力和Service相似，服务是无状态的，但状态却是Actor模型的特点。一个无状态的领域服务一般使用单例模式，而当一个类有了状态，就好像一个物体有了生命，“我是谁？我在哪？”这些也都成了它所需要关心的问题。我们需要维护服务列表、制定路由规则、实现服务发现功能...写到这，我们可以发现这些和微服务的服务治理非常相似。所以，我们可以建立我们的“注册中心”封装select,create,actorof等Akka的操作来实现服务发现，还能在里面提供限流、熔断、合并等等扩展。 面向对象 DDD是一种方法论，它的本质还是面向对象的思想。DDD在OOAD的基础上提炼演进出了一套架构设计理论。帮助我们，使我们能更容易的以面对对象的思想来设计工程。DDD的设计也需要遵循OOAD的SOLID原则。 Effective Aggregate Design by Vaughn Vernon The Clean Code Blog by Robert C. Martin (Uncle Bob) Reactive-Systems-Akka-Actors-DomainDrivenDesign 复杂度应对之道 - COLA应用架构
领域驱动设计（DDD）实践之路（第二篇)
在领域驱动里面，infrastructure作为基础设施，是提供技术细节的模块。需要强调的是，很多人会误以为infrastructure就是传统的DAO层，其实infrastructure包括但不限于DAO层，比如文件处理，三方调用，使用缓存，发送异步消息等具体的技术细节实现都存在于infrastructure层。那么技术细节是什么呢。在我们看来，技术细节包含以下特征
案例1：我们的实体需要持久化（存储），所以我们需要提供存储的实现。领域层的repository.save等方法提供了持久化接口约定，对于infrastructure来说，如何实现这个方法的代码，就是技术细节。那么我们如何实现这个过程呢？自然是选择缓存，OSS存或者数据库存。如果选择数据库，则进而需要选择orm框架，配置...，实现repository.save的接口，这些都属于持久化所需的技术细节代码。
案例2：我们的应用需要导出资产包相关的excel形式数据，那么当导出资产包数据时，文件领域模块提供了导出的统一接口，资产领域模块提供了资产包的适配接口，而导出excel的代码需要使用easyExcel或者POI等第三方框架，属于技术细节代码。
案例3: 接案例2，为了实现导出时所需的excel排版格式，排版本身的格式与业务有关，比如在我们的业务场景下，我们导出调解明细（我们项目特定的一个领域模型）的时候，只需要按照常见的导出方式即可，而导出资产明细（我们项目特定的一个领域模型）则需要解析拼接所有的动态数据列，合并显示每条数据不同的动态列，而这一切是由业务决定的。根据业务不同有不同的排版要求这一点体现了资产域需要提供文件域的导出策略，调解域也需要实现文件域的导出策略。这些都属于描述业务信息的约定，而这些约定的具体实现比如怎么把实体的那一个属性映射到excel的哪一行哪一列，则属于技术细节。这种区分方式显性化了业务的概念，同时又将实现放在了基础设施层，提供了一定的解耦性。
说完了infrastructure的技术细节的定义，我们接下来聊几个在采用DDD研发模式下，infrastructure层开发过程中经常会遇到的一些问题及我们的解决方案。
为了让业务逻辑和代码实现解耦，在repository的约定中，我们通常用“save保存”代替我们通常说的“insert（插入）“，”update（更新）”这样的技术术语，以屏蔽技术细节。这样带来的一个副作用是，在save时就需要根据策略判断调用insert还是update，我们使用的策略是根据id是否是空决定，即我们所有的实体对象都有一个属性，类型为Id类的子类，id对象的属性（数据库里面实际存放的id值）可能为null，但是id对象，本身不会为null，根据这个对象可以判断当前实体id是否为空。
对于聚合场景，子实体是需要知道聚合根的id的，因为在存储到数据库时可能需要以外键的方式存储对象间的映射关系。
然而，在具体实现中，我们认为，实体之间的对象关系才是标识两个实体之间关系的方式，而不是id，所以生成实体时，先通过对象引用关联对象，表明聚合和实体之间的关系，在保存到数据库的时候，通过实体生成数据库映射类的时候就可以知道当前数据的id是否为空，同时又能知道当前数据之间的关系。
对象之间的关系在1:1聚合保存的时候可能体现不明显，但是当1:N或者N:N批量保存聚合的时候，作用就比较明显了。在我们的系统中发起调解业务就需要批量保存调解批次。代码如下（欢迎吐槽，拥抱进步）
通过这种方式就解决了批量插入不能返回id，同时又能继续复用id.isNew()判断是否为新数据的方式（这里我们没有创建entity基类，所以判断放在了Id上）。
以上方法提供了批量保存时如何区分是新增还是更新。下面我们来谈谈我们项目内提供的插入和更新模板代码。
对于领域来说，save是基本的保存代码。方法传入的参数往往是一个存在于内存中的聚合根对象，有时包含全量的子实体，VO和全量的字段，而在插入场景，对批量请求我们希望支持批量插入，减少对数据库的IO频率，在更新场景下，我们希望减少update时的更新字段的数量（只更新需要更新的字段），这有助于减少数据库IO次数、binlog大小和mysql数据库索引变更带来的开销，所以是非常有必要的。因此对于infrastructure来说，可以提供统一的定制化模板方便repository定制化更新字段的方法快速实现。
由于我们的系统使用的是mybatisplus的ORM方案，所以我们根据api和mysql的批量语句开关提供了一个批量插入和批量更新的Mapper基类，其中insertBatchSomColumn是mybatisplus自带的，updateBatchById则是我们实现的，文档链接如下https://mp.toutiao.com/profile_v4/graphic/preview?pgc_id=7062223527654916621通过这种方式可以轻松地提供定制化更新某几列的sql，减轻sql编写负担。
这一次要讲的其实就是上面提到过的excel导入导出的案例。对于我们的系统来说，具有资产域，文件域，调解域等。其中资产域、调节域等三个域需要导入导出excel。但是我们在设计的时候认为文件的操作属于文件域的概念，所以应当由文件的domain提供功能。但是很明显，具体的导入导出的策略根据数据的不同是可以变化的。所以针对这种情况，我们回归到领域驱动的实现的本质------面向对象技术来思考这个问题的优雅解法。以导入为例
代码如下
上面4份代码是domain的，最下面的是infrastructure的，这里我们只讲infrastructure的（但是我个人认为领域分层后还是需要整体考虑的，所以才会贴上domain的代码）。
这是我们对于跨域业务逻辑的处理办法。
为了保证各领域模型间的解耦，我们经常通过最轻量级的领域事件的方式实现，而不是类似metaq，msgbroker这样的异步分布式消息中间件。领域事件的发送有很多的实现方案，我们倾向于直接使用spring的功能，因为我们需要同步保证事务。但是spring的event发送需要继承ApplicationEvent而领域事件我们又希望独立于spring的event体系，所以我们通过对spring的了解发现了spring已经提供了 PayloadApplicationEvent 可以实现这种功能实现上和其他的spring的event一致，获取我们自己定义的event的方法如下
这里的getPayload()可以获取到我们放进去的领域事件TimeoutEvent
在任何系统中都会有批处理的业务。可能是批处理聚合，可能是批处理聚合内的实体类。这里说一下我之前遇到的一个帖子（jdon）上的讨论。帖子上说的是有一个排班业务，一条班表数据作为聚合存在着每日排班子实体，每日排班下又存在着排班明细子实体，当日期逐渐增加时一条排班需要加载好几年的数据用于生成聚合，而实际上则仅仅只需要计算最近几周的数据。这里存在两点问题
第一点自然不用多说，技术实现以提供业务功能为核心是我一直以来的主张。所以当数据量可能会不断增大的情况下不用加载完整自然是必须的（哪怕内存存储的下也应当尽可能少的消耗）。第二点来说帖子的一位回复者倾向于DomainService提供专门的适配方法，用于加载几周的数据。
我们的系统中存在一个有一些类似的业务。我们的系统需要每隔几分钟就运行一次批处理任务，获取所有已经过期的调解明细，并且设置为过期。调解明细属于调解批次的聚合，所以我们有同样的需求。
我们在此提供一种我们的实现，供参考。
repository的实现根据面向对象原则，仅仅提供如何查询过滤数据库数据
迭代器的实现提供了迭代职责实现
至此实现了批处理加载聚合的逻辑，同时可以提供聚合的部分加载（需要注意业务的正确性不会因为聚合的不完全加载而产生问题）。
最后总结一下
