ddd67：【DDD】全网最详细2万字讲解DDD，从理论到实战(代码示例) 2024-05-06 16:06:53 0 0 文章目录基础概念领域限界上下文贫血模型和充血模型贫血模型充血模型实体和值对象实体值对象聚合聚合根领域事件领域事件相关案例事件风暴DDD分层架构用户接口层应用层领域层基础层架构原则防腐层(ACL)服务的调用微服务内跨层服务调用微服务之间的服务调用领域事件驱动服务依赖DDD代码模型用户接口层应用层领域层基础层目录结构例子数据对象视图基础层领域层应用层用户接口层前端应用基于DDD的微服务设计实例总结文章链接 本篇文章是我购买了极客时间的课程《DDD 实战课》，将里面的重要内容摘抄出来做的学习笔记，并添加了一些个人理解进去，理论+实战结合。有代码示例。文末会放上一些我看过的DDD优秀文章的链接。 因为是个人笔记，所以没讲究文字排版与样式，但是内容绝对干货 DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。 基础概念 领域 领域就是用来确定范围的，范围即边界，这也是 DDD 在设计中不断强调边界的原因。简言之，DDD 的领域就是这个边界内要解决的业务问题域。 领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。领域可以拆分为多个子领域。一个领域相当于一个问题域，领域拆分为子域的过程就是大问题拆分为小问题的过程。 其实很好理解，DDD 的研究方法与自然科学的研究方法类似。当人们在自然科学研究中遇到复杂问题时，通常的做法就是将问题一步一步地细分，再针对细分出来的问题域，逐个深入研究，探索和建立所有子域的知识体系。当所有问题子域完成研究时，我们就建立了全部领域的完整知识体系了 在领域不断划分的过程中，领域会细分为不同的子域，子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。 决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。还有一种功能子域是必需的，但既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，它就是支撑域。 这三类子域相较之下，核心域是最重要的，我们下面讲目的的时候还会以核心域为例详细介绍。通用域和支撑域如果对应到企业系统，举例来说的话，通用域则是你需要用到的通用系统，比如认证、权限等等，这类应用很容易买到，没有企业特点限制，不需要做太多的定制化。而支撑域则具有企业特性，但不具有通用性，例如数据代码类的数据字典等系统。 聚合根与领域服务负责封装实现业务逻辑。领域服务负责对聚合根进行调度和封装，同时可以对外提供各种形式的服务，对于不能直接通过聚合根完成的业务操作就需要通过领域服务。 说白了就是，聚合根本身无法完全处理这个逻辑，例如支付这个步骤，订单聚合不可能支付，所以在订单聚合上架一层领域服务，在领域服务中实现支付逻辑，然后应用服务调用领域服务。 遵守以下规范：同限界上下文内的聚合之间的领域服务可直接调用两个限界上下文的交互必须通过应用服务层抽离接口->适配层适配。 例子，用户升职，上级领导要变，上级领导的下属要变代码如下：/** * @Author WDYin * @Date 2022/5/15 **/@Servicepublic class UserDomainServiceImpl implements UserDomainService { @Override public void promote(User user, User leader) { //保存领导 user.saveLeader(leader); //领导增加下属 leader.increaseSubordination(user); }} 限界上下文 我们可以将限界上下文拆解为两个词：限界和上下文。限界就是领域的边界，而上下文则是语义环境。通过领域的限界上下文，我们就可以在统一的领域边界内用统一的语言进行交流，简单来说限界上下文可以理解为语义环境。 综合一下，我认为限界上下文的定义就是：用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。 在一个明媚的早晨，孩子起床问妈妈：“今天应该穿几件衣服呀？”妈妈回答：“能穿多少就穿多少！”那到底是穿多还是穿少呢？ 如果没有具体的语义环境，还真不太好理解。但是，如果你已经知道了这句话的语义环境，比如是寒冬腊月或者是炎炎夏日，那理解这句话的涵义就会很容易了。 所以语言离不开它的语义环境。 而业务的通用语言就有它的业务边界，我们不大可能用一个简单的术语没有歧义地去描述一个复杂的业务领域。限界上下文就是用来细分领域，从而定义通用语言所在的边界。 正如电商领域的商品一样，商品在不同的阶段有不同的术语，在销售阶段是商品，而在运输阶段则变成了货物。同样的一个东西，由于业务领域的不同，赋予了这些术语不同的涵义和职责边界，这个边界就可能会成为未来微服务设计的边界。看到这，我想你应该非常清楚了，领域边界就是通过限界上下文来定义的。 理论上限界上下文就是微服务的边界。我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。 可以说，限界上下文是微服务设计和拆分的主要依据。在领域模型中，如果不考虑技术异构、团队沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务。 贫血模型和充血模型 贫血模型 贫血模型具有一堆属性和set get方法，存在的问题就是通过pojo这个对象上看不出业务有哪些逻辑，一个pojo可能被多个模块调用，只能去上层各种各样的service来调用，这样以后当梳理这个实体有什么业务，只能一层一层去搜service，也就是贫血失忆症，不够面向对象。 充血模型 比如如下user用户有改密码，改手机号，修改登录失败次数等操作，都内聚在这个user实体中，每个实体的业务都是清晰的，就是充血模型，充血模型的内存计算会多一些，内聚核心业务逻辑处理。 说白了就是，不只是有贫血模型中setter getter方法，还有其他的一些业务方法，这才是面向对象的本质，通过user实体就能看出有哪些业务存在。@NoArgsConstructor@Getterpublic class User extends Aggregate<Long, User> { /** * 用户名 */ private String userName; /** * 姓名 */ private String realName; /** * 手机号 */ private String phone; /** * 密码 */ private String password; /** * 锁定结束时间 */ private Date lockEndTime; /** * 登录失败次数 */ private Integer failNumber; /** * 用户角色 */ private List<Role> roles; /** * 部门 */ private Department department; /** * 用户状态 */ private UserStatus userStatus; /** * 用户地址 */ private Address address; public User(String userName, String phone, String password) { saveUserName(userName); savePhone(phone); savePassword(password); } /** * 保存用户名 * @param userName */ private void saveUserName(String userName) { if (StringUtils.isBlank(userName)){ Assert.throwException("用户名不能为空！"); } this.userName = userName; } /** * 保存电话 * @param phone */ private void savePhone(String phone) { if (StringUtils.isBlank(phone)){ Assert.throwException("电话不能为空！"); } this.phone = phone; } /** * 保存密码 * @param password */ private void savePassword(String password) { if (StringUtils.isBlank(password)){ Assert.throwException("密码不能为空！"); } this.password = password; } /** * 保存用户地址 * @param province * @param city * @param region */ public void saveAddress(String province,String city,String region){ this.address = new Address(province,city,region); } /** * 保存用户角色 * @param roleList */ public void saveRole(List<Role> roleList) { if (CollectionUtils.isEmpty(roles)){ Assert.throwException("角色不能为空！"); } this.roles = roleList; }} 实体和值对象 实体 实体和值对象这两个概念都是领域模型中的领域对象。实体和值对象是组成领域模型的基础单元。 在代码模型中，实体的表现形式是实体类，这个类包含了实体的属性和方法，通过这些方法实现实体自身的业务逻辑。在 DDD 里，这些实体类通常采用充血模型，与这个实体相关的所有业务逻辑都在实体类的方法中实现，跨多个实体的领域逻辑则在领域服务中实现。 实体以 DO（领域对象）的形式存在，每个实体对象都有唯一的 ID。比如商品是商品上下文的一个实体，通过唯一的商品 ID 来标识，不管这个商品的数据如何变化，商品的 ID 一直保持不变，它始终是同一个商品。 在领域模型映射到数据模型时，一个实体可能对应 0 个、1 个或者多个数据库持久化对象。大多数情况下实体与持久化对象是一对一。在某些场景中，有些实体只是暂驻静态内存的一个运行态 实体，它不需要持久化。比如，基于多个价格配置数据计算后生成的折扣实体。 而在有些复杂场景下，实体与持久化对象则可能是一对多或者多对一的关系。比如，用户 user 与角色 role 两个持久化对象可生成权限实体，一个实体对应两个持久化对象，这是一对多的场景。再比如，有些场景为了避免数据库的联表查询，提升系统性能，会将客户信息 customer 和账户信息 account 两类数据保存到同一张数据库表中，客户和账户两个实体可根据需要从一个持久化对象中生成，这就是多对一的场景。 权限管理系统——用户实体，代码如下：@NoArgsConstructor@Getterpublic class User extends Aggregate<Long, User> { /** * 用户id-聚合根唯一标识 */ private UserId userId; /** * 用户名 */ private String userName; /** * 姓名 */ private String realName; /** * 手机号 */ private String phone; /** * 密码 */ private String password; /** * 锁定结束时间 */ private Date lockEndTime; /** * 登录失败次数 */ private Integer failNumber; /** * 用户角色 */ private List<Role> roles; /** * 部门 */ private Department department; /** * 领导 */ private User leader; /** * 下属 */ private List<User> subordinationList = new ArrayList<>(); /** * 用户状态 */ private UserStatus userStatus; /** * 用户地址 */ private Address address; public User(String userName, String phone, String password) { saveUserName(userName); savePhone(phone); savePassword(password); } /** * 保存用户名 * @param userName */ private void saveUserName(String userName) { if (StringUtils.isBlank(userName)){ Assert.throwException("用户名不能为空！"); } this.userName = userName; } /** * 保存电话 * @param phone */ private void savePhone(String phone) { if (StringUtils.isBlank(phone)){ Assert.throwException("电话不能为空！"); } this.phone = phone; } /** * 保存密码 * @param password */ private void savePassword(String password) { if (StringUtils.isBlank(password)){ Assert.throwException("密码不能为空！"); } this.password = password; } /** * 保存用户地址 * @param province * @param city * @param region */ public void saveAddress(String province,String city,String region){ this.address = new Address(province,city,region); } /** * 保存用户角色 * @param roleList */ public void saveRole(List<Role> roleList) { if (CollectionUtils.isEmpty(roles)){ Assert.throwException("角色不能为空！"); } this.roles = roleList; } /** * 保存领导 * @param leader */ public void saveLeader(User leader) { if (Objects.isNull(leader)){ Assert.throwException("leader不能为空！"); } this.leader = leader; } /** * 增加下属 * @param user */ public void increaseSubordination(User user) { if (null == user){ Assert.throwException("leader不能为空！"); } this.subordinationList.add(user); }} 值对象 简单来说，值对象本质上就是一个集。那这个集合里面有什么呢？若干个用于描述目的、具有整体概念和不可修改的属性。那这个集合存在的意义又是什么？在领域建模的过程中，值对象可以保证属性归类的清晰和概念的完整性，避免属性零碎。 举例代码如下：/** * 地址数据 */@Getterpublic class Address extends ValueObject { /** * 省 */ private String province; /** * 市 */ private String city; /** * 区 */ private String region; public Address(String province, String city, String region) { if (StringUtils.isBlank(province)){ Assert.throwException("province不能为空！"); } if (StringUtils.isBlank(city)){ Assert.throwException("city不能为空！"); } if (StringUtils.isBlank(region)){ Assert.throwException("region不能为空！"); } this.province = province; this.city = city; this.region = region; }} 值对象与实体一起构成聚合。值对象逻辑上是实体属性的一部分，用于描述实体的特征。值对象创建后就不允许修改了，只能用另外一个值对象来整体替换。值对象是一些不会修改，只能完整替换的属性值的集合，你更关注他的属性和值，它没有太多的业务行为，用于描述实体的一些属性集，被实体引用，依附于实体的值对象基本没有自己的数据库表。是否要设计成值对象，你要看这个对象是否后续还会来回修改，会不会有生命周期。如果不可修改，并且以后也不会专门针对它进行查询或者统计，你就可以把它设计成值对象，如果不行，那就设计成实体吧。 在领域建模时，我们可以将部分对象设计为值对象，保留对象的业务涵义，同时又减少了实体的数量；在数据建模时，我们可以将值对象嵌入实体，减少实体表的数量，简化数据库设计。 同样的对象在不同的场景下，可能会设计出不同的结果。有些场景中，地址会被某一实体引用，它只承担描述实体的作用，并且它的值只能整体替换，这时候你就可以将地址设计为值对象，比如收货地址。而在某些业务场景中，地址会被经常修改，地址是作为一个独立对象存在的，这时候它应该设计为实体，比如行政区划中的地址信息维护。 聚合 实体和值对象是很基础的领域对象。实体一般对应业务对象，它具有业务属性和业务行为；而值对象主要是属性集合，对实体的状态和特征进行描述。但实体和值对象都只是个体化的对象，它们的行为表现出来的是个体的能力。 你可以这么理解，聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。 聚合在 DDD 分层架构里属于领域层，领域层包含了多个聚合，共同实现核心业务逻辑。 聚合根 如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不仅是实体，还是聚合的管理者。 首先它作为实体本身，拥有实体的属性和业务行为，实现自身的业务逻辑。 其次它作为聚合的管理者，在聚合内部负责协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑。 最后在聚合之间，它还是聚合对外的接口人，以聚合根 ID 关联的方式接受外部任务和请求，在上下文内实现聚合之间的业务协同。也就是说，聚合之间通过聚合根 ID 关联引用，如果需要访问其它聚合的实体，就要先访问聚合根，再导航到聚合内部实体，外部对象不能直接访问聚合内实体。 领域事件 举例来说的话，领域事件可以是业务流程的一个步骤，比如投保业务缴费完成后，触发投保单转保单的动作；也可能是定时批处理过程中发生的事件，比如批处理生成季缴保费通知单，触发发送缴费邮件通知操作；或者一个事件发生后触发的后续动作，比如密码连续输错三次，触发锁定账户的动作。 在做用户旅程或者场景分析时，我们要捕捉业务、需求人员或领域专家口中的关键词：“如果发生……，则……”“当做完……的时候，请通知……”“发生……时，则……”等。在这些场景中，如果发生某种事件后，会触发进一步的操作，那么这个事件很可能就是领域事件。 领域事件相关案例 我来给你介绍一个保险承保业务过程中有关领域事件的案例。 一个保单的生成，经历了很多子域、业务状态变更和跨微服务业务数据的传递。这个过程会产生很多的领域事件，这些领域事件促成了保险业务数据、对象在不同的微服务和子域之间的流转和角色转换。在下面这张图中，我列出了几个关键流程，用来说明如何用领域事件驱动设计来驱动承保业务流程。 事件起点：客户购买保险 - 业务人员完成保单录入 - 生成投保单 - 启动缴费动作。 总之，通过领域事件驱动的异步化机制，可以推动业务流程和数据在各个不同微服务之间的流转，实现微服务的解耦，减轻微服务之间服务调用的压力，提升用户体验。 一个完整的领域事件 = 事件发布 + 事件存储 + 事件分发 + 事件处理。 事件发布：构建一个事件，需要唯一标识，然后发布； 事件存储：发布事件前需要存储，因为接收后的事件也会存储，可用于重试或对账等；就是每次执行一次具体的操作时，把行为记录下来，执行持久化。 事件分发：服务内的应用服务或者领域服务直接发布给订阅者，服务外需要借助消息中间件，比如Kafka，RabbitMQ等，支持同步或者异步。 事件处理：先将事件存储，然后再处理。 当然了，实际开发中事件存储和事件处理不是必须的。 因此实现方案：发布订阅模式，分为跨上下文（kafka，RocketMq）和上下文内（spring事件，Guava Event Bus）的领域事件。 用户注册后，发送短信和邮件，使用spring事件实现领域事件代码如下：/** * 用户注册事件 * @Author WDYin **/public class UserRegisterEvent extends ApplicationEvent { public UserRegisterEvent(Object source) { super(source); }}/** * 用户监听事件 * @Author WDYin **/@Componentpublic class UserListener { @EventListener(UserRegisterEvent.class) public void userRegister(UserRegisterEvent event) { User user = (User) event.getSource(); System.out.println("用户注册。。。发送短信。。。" + user); System.out.println("用户注册。。。发送邮件。。。" + user); } @EventListener(UserCancelEvent.class) public void userCancelEvent(UserCancelEvent event) { User user = (User) event.getSource(); System.out.println("用户注销。。。" + user); } }/** * 发布用户注册事件 * @Author : WDYin */@RunWith(value = SpringJUnit4ClassRunner.class)@SpringBootTest(classes = DemoApplication.class)public class MyClient { @Autowired private ApplicationContext applicationContext; @Test public void test() { User user = new User(); //发布事件 applicationContext.publishEvent(new UserRegisterEvent(user)); }} 事件风暴 DDD分层架构 DDD 的分层架构在不断发展。最早是传统的四层架构；再后来领域层和应用层之间增加了上下文环境（Context）层，五层架构（DCI）就此形成了。 用户接口层 用户接口层是前端应用和微服务之间服务访问和数据交换的桥梁。它处理前端发送的Restful 请求和解析用户输入的配置文件等，将数据传递给应用层。或获取应用服务的数据后，进行数据组装，向前端提供数据服务。主要服务形态是 Facade 服务。Facade 服务分为接口和实现两个部分。完成服务定向，DO 与 DTO 数据的转换和组装，实现前端与应用层数据的转换和交换。 ①一般包括用户接口、Web 服务、rpc请求，mq消息等外部输入均被视为外部输入的请求。对外暴露API，具体形式不限于RPC、Rest API、消息等。 ②一般都很薄，提供必要的参数校验和异常捕获流程。 ③一般会提供VO或者DTO到Entity或者ValueObject的转换，用于前后端调用的适配，当然dto可以直接使用command和query，视情况而定。 ④用户接口层很重要，在于前后端调用的适配。若你的微服务要面向很多应用或渠道提供服务，而每个渠道的入参出参都不一样，你不太可能开发出太多应用服务，这样Facade接口就起很好的作用了，包括DO和DTO对象的组装和转换等。 应用层 应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。但应用层又位于领域层之上，因为领域层包含多个聚合，所以它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。除了同步方法调用外，还可以发布或者订阅领域事件，权限校验、事务控制，一个事务对应一个聚合根。 应用层负责不同聚合之间的服务和数据协调，负责微服务之间的事件发布和订阅。通过应用服务对外暴露微服务的内部功能，这样就可以隐藏领域层核心业务逻辑的复杂性以及内部实现机制。应用层的主要服务形态有：应用服务、事件发布和订阅服务。应用服务内用于组合和编排的服务，主要来源于领域服务，也可以是外部微服务的应用服务。 领域层 领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。 这里我要特别解释一下其中几个领域对象的关系，以便你在设计领域层的时候能更加清楚。首先，领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。其次，你要知道，实体和领域对象在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。 领域层主要的服务形态有实体方法和领域服务。实体采用充血模型，在实体类内部实现实体相关的所有业务逻辑，实现的形式是实体类中的方法。实体是微服务的原子业务逻辑单元。在设计时我们主要考虑实体自身的属性和业务行为，实现领域模型的核心基础能力。不必过多考虑外部操作和业务流程，这样才能保证领域模型的稳定性。 ①包含了业务核心的领域模型：实体（聚合根+值对象），使用充血模型实现所有与之相关的业务功能，主要表达业务概念，业务状态信息以及业务规则。 ②真正的业务逻辑都在领域层编写，聚合根负责封装实现业务逻辑，对应用层暴露领域级别的服务接口。 ③聚合根不能直接操作其它聚合根，聚合根与聚合根之间只能通过聚合根ID引用；同限界上下文内的聚合之间的领域服务可直接调用；两个限界上下文的交互必须通过应用服务层抽离接口->适配层适配。 ④跨实体的状态变化，使用领域服务，领域服务不能直接修改实体的状态，只能调用实体的业务方法 DDD 提倡富领域模型，尽量将业务逻辑归属到实体对象上，实在无法归属的部分则设计成领域服务。领域服务会对多个实体或实体方法进行组装和编排，实现跨多个实体的复杂核心业务逻辑。对于严格分层架构，如果单个实体的方法需要对应用层暴露，则需要通过领域服务封装后才能暴露给应用服务 基础层 也叫基础设施层，基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。 基础层的服务形态主要是仓储服务。仓储服务包括接口和实现两部分。仓储接口服务供应用层或者领域层服务调用，仓储实现服务，完成领域对象的持久化或数据初始化。 比如说，在传统架构设计中，由于上层应用对数据库的强耦合，很多公司在架构演进中最担忧的可能就是换数据库了，因为一旦更换数据库，就可能需要重写大部分的代码，这对应用来说是致命的。那采用依赖倒置的设计以后(说白了就是多套一层接口)，应用层就可以通过解耦来保持独立的核心业务 ①为业务逻辑提供支撑能力，提供通用的技术能力，仓库写增删改查类似DAO。 ② 防腐层实现(封装变化)用于业务检查和隔离第三方服务，内部try catch 架构原则 在《实现领域驱动设计》一书中，DDD 分层架构有一个重要的原则：每层只能与位于其下方的层发生耦合。 而架构根据耦合的紧密程度又可以分为两种：严格分层架构和松散分层架构。优化后的DDD 分层架构模型就属于严格分层架构，任何层只能对位于其直接下方的层产生依赖。而传统的 DDD 分层架构则属于松散分层架构，它允许某层与其任意下方的层发生依赖。那我们怎么选呢？综合我的经验，为了服务的可管理，我建议你采用严格分层架构。 在严格分层架构中，领域服务只能被应用服务调用，而应用服务只能被用户接口层调用，服务是逐层对外封装或组合的，依赖关系清晰。而在松散分层架构中，领域服务可以同时被应用层或用户接口层调用，服务的依赖关系比较复杂且难管理，甚至容易使核心业务逻辑外泄。试想下，如果领域层中的某个服务发生了重大变更，那该如何通知所有调用方同步调整和升级呢？但在严格分层架构中，你只需要逐层通知上层服务就可以了。 防腐层(ACL) 当某个功能模块需要依赖第三方系统提供的数据或者功能时，我们常用的策略就是直接使用外部系统的API、数据结构。这样存在的问题就是，因使用外部系统，而被外部系统的质量问题影响，从而“腐化”本身设计的问题。 因此我们的解决方案就是在两个系统之间加入一个中间层，隔离第三方系统的依赖，对第三方系统进行通讯转换和语义隔离，这个中间层，我们叫它防腐层 说白了就是，两个系统之间加了中间层，中间层类似适配器模式，解决接口差异的对接，接口转换是单向的（即从调用方向被调用方进行接口转换）；防腐层强调两个子系统语义解耦，接口转换是双向的。 服务的调用 微服务内跨层服务调用 微服务架构下往往采用前后端分离的设计模式，前端应用独立部署。前端应用调用发布在API 网关上的 Facade 服务，Facade 定向到应用服务。应用服务作为服务组织和编排者，它的服务调用有这样两种路径： 第一种是应用服务调用并组装领域服务。此时领域服务会组装实体和实体方法，实现核心领域逻辑。领域服务通过仓储服务获取持久化数据对象，完成实体数据初始化。 第二种是应用服务直接调用仓储服务。这种方式主要针对像缓存、文件等类型的基础层数据访问。这类数据主要是查询操作，没有太多的领域逻辑，不经过领域层，不涉及数据库持久化对象。 微服务之间的服务调用 微服务之间的应用服务可以直接访问，也可以通过 API 网关访问。由于跨微服务操作，在进行数据新增和修改操作时，你需关注分布式事务，保证数据的一致性。 领域事件驱动 领域事件驱动包括微服务内和微服务之间的事件。微服务内通过事件总线（EventBus）完成聚合之间的异步处理。微服务之间通过消息中间件完成。异步化的领域事件驱动机制是一种间接的服务访问方式。当应用服务业务逻辑处理完成后，如果发生领域事件，可调用事件发布服务，完成事件发布。当接收到订阅的主题数据时，事件订阅服务会调用事件处理领域服务，完成进一步的业务操作。 服务依赖 DDD 分层架构有一个重要的原则就是：每层只能与位于其下方的层发生耦合。 那根据耦合的紧密程度，分层架构可以分为两种：严格分层架构和松散分层架构。在严格分层架构中，任何层只能与位于其直接下方的层发生依赖。在松散分层架构中，任何层可以与其任意下方的层发生依赖。 在松散分层架构中，领域层的实体方法和领域服务可以直接暴露给应用层和用户接口层。松散分层架构的服务依赖关系，无需逐级封装，可以快速暴露给上层。 但它存在一些问题，第一个是容易暴露领域层核心业务的实现逻辑；第二个是当实体方法或领域服务发生服务变更时，由于服务同时被多层服务调用和组合，不容易找出哪些上层服务调用和组合了它，不方便通知到所有的服务调用方。 严格分层架构可以避免将核心业务逻辑的实现暴露给外部，将实体和方法封装成领域服务，也可以避免在应用层沉淀过多的本该属于领域层的核心业务逻辑，避免应用层变得臃肿。还有就是当服务发生变更时，由于服务只被紧邻上层的服务调用和组合，你只需要逐级告知紧邻上层就可以了，服务可管理性比松散分层架构要好是一定的。 DDD代码模型 用户接口层 Interfaces 的代码目录结构有：assembler、dto 和 facade 三类。 Assembler：实现 DTO 与领域对象之间的相互转换和数据交换。一般来说 Assembler 与DTO 总是一同出现。 Dto：它是数据传输的载体，内部不存在任何业务逻辑，我们可以通过 DTO 把内部的领域对象与外界隔离。 Facade：提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理。 应用层 Application 的代码目录结构有：event 和 service。 Event（事件）：这层目录主要存放事件相关的代码。它包括两个子目录：publish 和subscribe。前者主要存放事件发布相关代码，后者主要存放事件订阅相关代码（事件处理相关的核心业务逻辑在领域层实现）。这里提示一下：虽然应用层和领域层都可以进行事件的发布和处理，但为了实现事件的统一管理，我建议你将微服务内所有事件的发布和订阅的处理都统一放到应用层，事件相关的核心业务逻辑实现放在领域层。通过应用层调用领域层服务，来实现完整的事件发布和订阅处理流程。 Service（应用服务）：这层的服务是应用服务。应用服务会对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务。应用服务主要实现服务组合和编排，是一段独立的业务逻辑。你可以将所有应用服务放在一个应用服务类里，也可以把一个应用服务设计为一个应用服务类，以防应用服务类代码量过大。 领域层 Domain 是由一个或多个聚合包构成，共同实现领域模型的核心业务逻辑。聚合内的代码模型是标准和统一的，包括：entity、event、repository 和 service 四个子目录。 Aggregate（聚合）：它是聚合软件包的根目录，可以根据实际项目的聚合名称命名，比如权限聚合。在聚合内定义聚合根、实体和值对象以及领域服务之间的关系和边界。聚合内实现高内聚的业务逻辑，它的代码可以独立拆分为微服务。以聚合为单位的代码放在一个包里的主要目的是为了业务内聚，而更大的目的是为了以后微服务之间聚合的重组。聚合之间清晰的代码边界，可以让你轻松地实现以聚合为单位的微服务重组，在微服务架构演进中有着很重要的作用。 Entity（实体）：它存放聚合根、实体、值对象以及工厂模式（Factory）相关代码。实体类采用充血模型，同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码 在领域服务中实现。 Event（事件）：它存放事件实体以及与事件活动相关的业务逻辑代码。 Service（领域服务）：它存放领域服务代码。一个领域服务是多个实体组合出来的一段业务逻辑。你可以将聚合内所有领域服务都放在一个领域服务类中，你也可以把每一个领域服务设计为一个类。如果领域服务内的业务逻辑相对复杂，我建议你将一个领域服务设计为一个领域服务类，避免由于所有领域服务代码都放在一个领域服务类中，而出现代码臃肿的问题。领域服务封装多个实体或方法后向上层提供应用服务调用。 Repository（仓储）：它存放所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法。为了方便聚合的拆分和组合，我们设定了一个原则：一个聚合对应一个仓储。 特别说明：按照 DDD 分层架构，仓储实现本应该属于基础层代码，但为了在微服务架构演进时，保证代码拆分和重组的便利性，我是把聚合仓储实现的代码放到了聚合包内。这样，如果需求或者设计发生变化导致聚合需要拆分或重组时，我们就可以将包括核心业务逻辑和仓储代码的聚合包整体迁移，轻松实现微服务架构演进。 基础层 Infrastructure 的代码目录结构有：config 和 util 两个子目录。 Config：主要存放配置相关代码。 Util：主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码，你可以为不同的资源类别建立不同的子目录。 在严格分层架构模式下，不允许服务的跨层调用，每个服务只能调用它的下一层服务。服务从下到上依次为：实体方法、领域服务和应用服务。如果需要实现服务的跨层调用，我们应该怎么办？我建议你采用服务逐层封装的方式。 目录结构例子││ ├─interface 用户接口层 │ │ └─controller 控制器，对外提供（Restful）接口│ │ └─facade 外观模式，对外提供本地接口和dubbo接口│ │ └─mq mq消息，消费者消费外部mq消息│ │ │ ├─application 应用层│ │ ├─assembler 装配器│ │ ├─dto 数据传输对象，xxxCommand/xxxQuery/xxxVo │ │ │ ├─command 接受增删改的参数│ │ │ ├─query 接受查询的参数│ │ │ ├─vo 返回给前端的vo对象│ │ ├─service 应用服务，负责领域的组合、编排、转发、转换和传递│ │ ├─repository 查询数据的仓库接口│ │ ├─listener 事件监听定义│ │ │ ├─domain 领域层│ │ ├─entity 领域实体│ │ ├─valueobject 领域值对象│ │ ├─service 领域服务│ │ ├─repository 仓库接口，增删改的接口│ │ ├─acl 防腐层接口│ │ ├─event 领域事件│ │ │ ├─infrastructure 基础设施层│ │ ├─converter 实体转换器│ │ ├─repository 仓库│ │ │ ├─impl 仓库实现│ │ │ ├─mapper mybatis mapper接口│ │ │ ├─po 数据库orm数据对象 │ │ ├─ack 实体转换器│ │ ├─mq mq消息│ │ ├─cache 缓存│ │ ├─util 工具类│ │ │ 数据对象视图 数据持久化对象 PO(Persistent Object)：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应 PO 的一个（或若干个）属性。最形象的理解就是一个 PO 就是数据库中的一条记录，好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。也有团队使用DO（Data Object）表示数据对象 领域对象 DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体，使用的是充血模型设计的对象。也有团队使用用 BO（Business Objects）表示业务对象的概念。 数据传输对象 DTO（Data Transfer Object）：数据传输对象，主要用于远程调用之间传输的对象的地方。比如我们一张表有 100 个字段，那么对应的 PO 就有 100 个属性。但是客户端只需要 10 个字段，没有必要把整个 PO 对象传递到客户端，这时我们就可以用只有这 10 个属性的 DTO 来传递结果到客户端，这样也不会暴露服务端表结构。到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为 VO。DTO泛指用于展示层与服务层之间的数据传输对象，当然VO也相当于数据DTO的一种。 视图对象 VO（View Object）：视图对象，主要对应界面显示的数据对象。对于一个WEB页面，小程序，微信公众号等前端需要的数据对象。也有团队用VO表示领域层中的Value Object值对象，这个要根据团队的规范来定义。 简单对象POJO（Plain Ordinary Java Object）：简单对象，是只具有setter getter方法对象的统称。但是不要把对象名命名成 xxxPOJO！ 我们结合下面这张图，看看微服务各层数据对象的职责和转换过程。 基础层 基础层的主要对象是 PO 对象。我们需要先建立 DO 和 PO 的映射关系。当 DO 数据需要持久化时，仓储服务会将 DO 转换为 PO 对象，完成数据库持久化操作。当 DO 数据需要初始化时，仓储服务从数据库获取数据形成 PO 对象，并将 PO 转换为 DO，完成数据初始化。大多数情况下 PO 和 DO 是一一对应的。但也有 DO 和 PO 多对多的情况，在 DO 和 PO数据转换时，需要进行数据重组 领域层 领域层的主要对象是 DO 对象。DO 是实体和值对象的数据和业务行为载体，承载着基础的核心业务逻辑。通过 DO 和 PO 转换，我们可以完成数据持久化和初始化。 应用层 应用层的主要对象是 DO 对象。如果需要调用其它微服务的应用服务，DO 会转换为DTO，完成跨微服务的数据组装和传输。用户接口层先完成 DTO 到 DO 的转换，然后应用服务接收 DO 进行业务处理。如果 DTO 与 DO 是一对多的关系，这时就需要进行 DO数据重组。 用户接口层 用户接口层会完成 DO 和 DTO 的互转，完成微服务与前端应用数据交互及转换。Facade服务会对多个 DO 对象进行组装，转换为 DTO 对象，向前端应用完成数据转换和传输。 前端应用 前端应用主要是 VO 对象。展现层使用 VO 进行界面展示，通过用户接口层与应用层采用DTO 对象进行数据交互。 基于DDD的微服务设计实例 代码示例 项目的目标是实现在线请假和考勤管理。功能描述如下： 1.请假人填写请假单提交审批，根据请假人身份、请假类型和请假天数进行校验，根据审批规则逐级递交上级审批，逐级核批通过则完成审批，否则审批不通过退回申请人。 2.根据考勤规则，核销请假数据后，对考勤数据进行校验，输出考勤统计。 总结 DDD 基于各种考虑，有很多的设计原则，也用到了很多的设计模式。条条框框多了，很多人可能就会被束缚住，总是担心或犹豫这是不是原汁原味的 DDD。其实我们不必追求极致的 DDD，这样做反而会导致过度设计，增加开发复杂度和项目成本。DDD 的设计原则或模式，是考虑了很多具体场景或者前提的。有的是为了解耦，如仓储服务、边界以及分层，有的则是为了保证数据一致性，如聚合根管理等。在理解了这些设计原则的根本原因后，有些场景你就可以灵活把握设计方法了，你可以突破一些原则，不必受限于条条框框，大胆选择最合适的方法。 文章链接 阿里技术专家详解 DDD 系列 第一讲- Domain Primitive 阿里技术专家详解DDD系列 第二讲 - 应用架构 阿里技术专家详解DDD系列 第三讲 - Repository模式 阿里技术专家详解DDD系列第四讲：领域层设计规范 阿里技术专家详解DDD系列第五讲：聊聊如何避免写流水账代码 2.5万字讲解DDD领域驱动设计，从理论到实践掌握DDD分层架构设计，赶紧收藏起来吧 收藏（0）