精选留言(141)

• 
  平平淡淡财是真

  2020-10-29

  老师你好，问一个对象命名的问题，例如：VO、DO、DTO、PO、POJO、Entity、model这些使用场景和代表的含义是什么？帖子上看的解释各不相同，很不确定。我的理解是这样的：VO=值对象、DO=PO=POJO=Entity=就是基础的实体对象，DTO=数据传输对象，model=前后端传输的数据模型。 请老师指点一下

  作者回复: 在传统的三层架构里面可能没有这么多的对象。而在DDD中增加这些对象主要是为了实现各层以及领域模型中DO对象与前端VO或传输对象DTO和后端数据库PO的解耦。 DDD中主要有一下几类对象。 数据持久化对象 (Persistent Object， PO)，与数据库结构一一映射，它是数据持久化过程中的数据载体。 领域对象（ Domain Object， DO），微服务运行时核心业务对象的载体， DO 一般包括实体或值对象。 数据传输对象（ Data Transfer Object， DTO），用于前端应用与微服务应用层或者微服务之间的数据组装和传输，是应用之间数据传输的载体。 视图对象（View Object， VO），用于封装展示层指定页面或组件的数据。 微服务基础层的主要数据对象是PO。在设计时，我们需要先建立DO和PO的映射关系。大多数情况下DO和PO是一一对应的。但也有DO和PO多对多的情况。在DO和PO数据转换时，需要进行数据重组。对于DO对象较多复杂的数据转换操作，你可以在聚合用工厂模式来实现。 当DO数据需要持久化时，先将DO转换为PO对象，由仓储实现服务完成数据库持久化操作。 当DO需要构建和数据初始化时，仓储实现服务先从数据库获取PO对象，将PO转换为DO后，完成DO数据构建和初始化。 领域层主要是DO对象。DO是实体和值对象的数据和业务行为载体，承载着基础的核心业务逻辑，多个依赖紧密的DO对象构成聚合。领域层DO对象在持久化时需要转换为PO对象。 应用层主要对象有DO对象，但也可能会有DTO对象。应用层在进行不同聚合的领域服务编排时，一般建议采用聚合根ID的引用方式，应尽量避免不同聚合之间的DO对象直接引用，避免聚合之间产生依赖。 在涉及跨微服务的应用服务调用时，在调用其他微服务的应用服务前，DO会被转换为DTO，完成跨微服务的DTO数据组装，因此会有DTO对象。 在前端调用后端应用服务时，用户接口层先完成DTO到DO的转换，然后DO作为应用服务的参数，传导到领域层完成业务逻辑处理。 用户接口层主要完成DO和DTO的互转，完成微服务与前端应用数据交互和转换。 facade接口服务在完成后端应用服务封装后，会对多个DO对象进行组装，转换为DTO对象，向前端应用完成数据转换和传输。 facade接口服务在接收到前端应用传入的DTO后，完成DTO向多个DO对象的转换，调用后端应用服务完成业务逻辑处理。 前端应用主要是VO对象。展现层使用VO进行界面展示，通过用户接口层与应用层采用DTO对象进行数据交互。

  共 4 条评论

  132
• 
  Jerry.hu

  2019-10-28

  老师能否结合一个实战的小项目进行讲解和梳理、同时可以将其项目贡享在git上 让大家结合实战 感觉效果会更好

  作者回复: 等我有时间的时候准备一下哈。现在的代码都是到类和方法级。

  共 7 条评论

  42
• 
  FlyFish

  2019-12-06

  老师好，可以具体讲讲domain层的service和application层service的区别吗，什么东西该房domian，什么该放application的service，然后application层app和aplication层的service具体又该如何界定，现在有点云里雾里，有点傻傻分不清楚

  作者回复: 我们先从底下往上逐层讲，单个实体自身的方法就是实体本身的业务行为。多个实体可组成更复杂的业务动作，这个是领域服务，实体的方法和领域服务共同构成领域模型的基础业务能力，这个能力是原子的基础的，不太考虑外界的用户行为和流程。而应用服务是对这些基础的能力进行组合和编排，它组合和编排的服务可以是跨聚合的领域服务，主要体现组合后的业务能力，更面向前端的用户操作，属于比较粗粒度的服务，通过编排可以更灵活应对外部需求变化。

  共 2 条评论

  30
• 
  How2Go

  2020-06-29

  已经结束的课程，老师还会回复吗？ ---------- 老师，这一节读了几遍，还没有太理解应用服务层。根据课程所说，我的理解是应用服务层会编排领域服务的执行，组织领域服务返回的结果。 但又不是API Gateway -- API Gateway 在基础层。 那么， 这个应用服务层， 是否就是BFF？

  作者回复: 应用层连接用户接口层和领域层，它是很薄的一层，主要职能是协调领域层多个聚合完成服务的组合和编排。 应用层之下是领域层，领域层是由多个业务职责单一的聚合构成，实现核心的领域逻辑。应用层负责协调领域层多个聚合的领域服务或领域对象，面向用例和业务流程完成服务的组合和编排。所以理论上应用层不应该实现领域模型的领域逻辑。这也是应用层为什么会很薄的原因。 应用层之上是用户接口层，在应用层完成领域层服务组合和编排后，应用服务被用户接口层Facade服务封装，完成接口和数据适配后，以粗粒度的服务通过API网关面向前端应用发布。 此外，应用层也是微服务之间服务调用的通道，微服务在应用层可以调用其他微服务的应用服务，完成微服务之间的服务组合和编排。 在应用层主要有应用服务、事件订阅和发布等相关代码逻辑。 其中，应用服务主要负责服务的组合、编排和转发，处理业务用例的执行顺序以及结果的拼装。在应用服务中还可以进行安全认证、权限校验、事务控制、领域事件发布或订阅等。 BFF是位于微服务之上，它的主要职责是负责微服务之间的服务协调和编排。而应用服务主要处理微服务内的服务组合和编排，它可以组合和编排领域服务。 在小型项目里，应用服务也可以编排其他微服务的应用服务，我们就没必要增加一层BFF的逻辑了。 在设计时我们应尽可能地将可复用的服务能力往下层沉淀，在实现能力复用的同时，还可以避免跨中心的服务调用。 BFF像齿轮一样，来适配前端应用与微服务之间的步调。通过BFF微服务中的façade接口服务向上适配不同的前端应用，通过协调不同微服务向下实现企业级业务能力的组合、编排和协同。 BFF微服务可根据需求和流程变化，与前端应用版本协同发布，避免微服务为适配不同前端需求的变化，而频繁地修改和发布版本，从而保证微服务版本和核心领域逻辑的稳定。

  共 5 条评论

  18
• 
  约书亚

  2019-10-29

  请问，最后图中MapperXML是什么？是mybatis那种做对象和数据库字段映射的xml文件么？如果是，那其中包含了与业务逻辑无关的数据库具体实现，放在领域层是否不太合适？

  作者回复: 是Mybatis的映射文件。 关于仓储，我是这么考虑的。仓储本身是属于基础层，但是考虑到一个聚合对应一个仓储，为了以后聚合代码整体迁移的方便，我在微服务代码目录设计时，在聚合目录下增加了一个Repository的仓储目录，跟仓储相关的代码都在这个目录下。 这个目录下的代码与聚合的其它业务代码是分开的。如果未来换数据库的话，只需要将Repository目录下的代码替换就可以了。而如果聚合需要整体迁移到其它微服务中去，仓储的代码也会一并迁移。

  共 6 条评论

  18
• 
  祥敏

  2019-11-06

  您好，根据三层架构和DDD四层架构映射这张图，以SSM框架组合谈谈我的理解和问题： 1.三层架构的业务接口层、业务逻辑层、数据访问层，对应实际开发的controller、service和dao三层； 2.图中三层架构中业务逻辑层的VO对应为四层架构中用户接口层的DTO，我的理解是VO原本就在三层架构的用户接口层，在三层架构中也会用DTO竖向穿透三层简化开发。图中的DTO划分为用户接口层，实际只是VO。 3.业务逻辑层中的service拆分为四层架构中的application service和domain service两层，如果以常见的CRUD开发来讲，domain service和applicatioin service是否在简单场景中就重叠了？ 4.三层开发中的仓储的依赖倒置已经实现了，mybatis层仓储接口被service层调用，mapper xml作为仓储的接口实现。如果采用DDD四层划分，mapper xml会被划分到基础层。repository aop这里的界面截指的是什么，是指ORM框架内部的bean与关系数据库实体之间的关系映射吗？ 5.聚合跟关注实体的持久化：聚合根、实体采用充血模型开发，CRUD中的CUD都会在聚合根、实体中实现，domain service 实现查询功能以及调用充血模型中的CUD方法，这样理解对吗？

  展开

  作者回复: 第一，可以这么理解。 第二，从本质来讲，DTO与VO都是对象。但是在DDD中将值传递的界限划分更细，比如DTO、DO、VO、PO，分别对应不同阶段的事务处理。DTO通常面向接口层，与VO相比可能会有前端应用/接口请求方要求的一些个性化的属性或值的映射等。 第三，简单部分可能会有重叠，但是基于不对外暴露领域层逻辑的目的，会将实体方法封装成领域服务，领域服务再封装为应用服务，然后对外暴露。 第四，这层本身是公共类，表示部分持久化的功能被提取为公共的面向切面聚合方法来实现 第五，是这样的。实体值对象的数据逻辑通过聚合根来管理，多实体的业务行为通过领域服务来组合。

  共 2 条评论

  14
• 
  Geek_d94e60

  2019-11-24

  老师您好，请教个问题，微服务拆分后，原来参数类或公共类业务数据 ，每个微服务都会用到，目前有两种方式处理 一，单独抽取一个公共服务，其它微服务都通过接口访问公共类或参数类数据 二，每个微服务都存放该类数据，但只能通过其中一个服务来维护，其它微服务走同步的方式保证数据的一致性 您比较推荐哪种呢？或者是否有其它的思路？

  展开

  作者回复: 你说的这个情况，我在第20讲的时候会讲到。 提前剧透一下哈。 跨库关联查询是分布式数据库的一个短板，会影响查询性能。在领域建模时，很多实体会分散到不同微服务中，但很多时候会因为业务需求，它们之间需要关联查询。 关联查询的业务场景包括两类：第一类是基于某一维度或某一主题域的数据查询，如基于客户全业务视图的数据查询，这种查询会跨多个业务线的微服务。第二类是表与表之间的关联查询，比如机构表与业务表的联表查询，但机构表和业务表分散在不同的微服务。那如何解决这两类关联查询呢？ 对于第一类场景，由于数据分散在不同微服务里，我们无法跨多个微服务来统计这些数据。你可以建立面向主题的分布式数据库，它的数据来源于不同业务的微服务。采用数据库日志捕获技术，从各业务端微服务将数据准实时汇集到主题数据库。在数据汇集时，提前做好数据关联（如将多表数据合并为一个宽表）或者建立数据模型。面向主题数据库建设查询微服务。这样一次查询你就可以获取客户所有维度的业务数据了。你还可以根据主题或场景设计合适的分库主键，提高查询效率。 对于第二类场景，对于不在同一个数据库的表与表的关联查询场景。你可以采用小表广播。在业务库中增加一张冗余的代码副表。当主表数据发生变化时，可以通过消息发布和订阅的领域事件驱动模式，异步刷新所有副表数据。这样既可解决表与表的关联查询，还可以提高数据的查询效率。

  共 10 条评论

  12
• 
  Jerry银银

  2019-12-17

  请教老师：解耦各层对基础层依赖，采用依赖倒置的方式？这有点抽象，不知道是通过什么的一种方法？

  作者回复: 给你看一个非常简单的例子，有Person聚合根，Person聚合包括仓储接口和仓储实现。 通过增加仓储服务，使得应用逻辑和数据库逻辑的依赖关系剥离，当换数据库的时候，只需要将仓储实现替换就可以了，这样不会对核心的业务逻辑产生影响。 /** * Person聚合根 */ public class Person{ private String id; private String name; private int age; private boolean gender； /** * 其它方法 */ } /** * Person仓储接口 */ public interface PersonRepositoryInterface { void save(Person person); void delete(String id); } /** *Person仓储实现 */ @Repository public class PersonRepositoryImp implements PersonRepositoryInterface { private PersonMapper mapper; public void save( Person person) { mapper.create(person); } public void delete((String id) { mapper.delete(id); } } 在应用逻辑中直接用仓储的接口就可以了，数据库相关的逻辑在PersonMapper里面实现。 PersonRepositoryInterface personRepos; personRepos.save(person)

  共 4 条评论

  10
• 
  密码123456

  2019-10-28

  感觉用户接口层，存在感好低。仅仅存在调用应用层。 为什么还要存在这个层级？是因为，需要限制用户接口的访问？

  作者回复: 用户接口层也很重要啊，主要前后端调用的适配。如果你的微服务要面向很多的应用或渠道提供服务，而每个渠道的入参和出参都不一样，你不太可能开发出太多的应用服务，这样Facade接口就起很好的作用了，包括DO和DTO对象的组装和转换等。

  共 4 条评论

  7
• 
  Jerry银银

  2019-12-16

  领域层之间能直接通信吗？ 还是说要交给应用层？

  作者回复: 领域层交互会增加聚合之间的耦合，不利于以后微服务的再次拆分和演进，聚合之间的交互建议通过应用服务来总体协调。

  共 2 条评论

  6
• 
  LY

  2019-10-28

  对今天的思考题不太理解，领域对象不应该是放在领悟层么，应用层只是会重建这些领域对象而已，所以应用层应该不会写领域对象的类才对。那又何来应用层有哪些对象的问题呢？

  作者回复: 领域对象的概念比较广泛，除了实体、值对象和聚合根外，服务也算是领域对象。领域层和应用分别有领域服务和应用服务。

  共 3 条评论

  6
• 
  Mr.Strive.Z.H.L

  2019-11-01

  老师你好，之前提过 实体是充血的，聚合根也是实体，对外提供该聚合的方法，聚合内实体的访问都必须通过聚合根，同时一个仓储对应一个聚合。我想问的是： 一个聚合内部有多个实体，那聚合根对外暴露的接口的方法岂不是非常多？？聚合内任意实体的增删改查，都通过聚合根这个充血模型对外提供？？ 感觉聚合的设计是非常有讲究的………

  作者回复: 聚合根主要负责数据和仓储相关的内容，也就是聚合数据持久化部分。业务逻辑主要还是实体方法以及领域服务。由于聚合根也可以组织多个实体，理论上聚合根的方法也可以实现领域服务的功能。多个实体的业务逻辑用领域服务或聚合根的方法都可以做到，具体选择哪种方式？结合场景或者开发习惯，选择自己最习惯的姿势。

  

  5
• 
  Geek_c1891e

  2020-12-26

  老师请教个问题:领域c需要用到领域b中访问数据库的一个方法3，但是领域b的聚合根没有对外封装暴露这个方法(可能是在领域b中在调用这个方法3之前有很多业务逻辑只适合领域b的业务)。像这种情况怎么做比较好？领域c直接倒置注入领域b访问数据库的方法3；还是让领域b封装暴露一个直接调整方法3的给领域c使用？还是有其他更好的方法？

  作者回复: 您说的领域C和领域B是不是两个不同的聚合。一般来说聚合之间尽量不要产生直接的服务调用，也不要产生实体之间的引用这种类型的耦合，当然聚合根ID引用这种除外。 看看这两种解决办法是否可以？第一种是领域B封装出一个领域服务，通过应用层的应用服务中，组合和编排领域C和领域B的领域服务，完成跨聚合的组合业务逻辑。第二种是通过领域事件机制，领域C完成业务逻辑后，通过事件总线将事件数据发送到领域b，在领域B中完成对应的业务逻辑，实现数据最终一致性。

  

  4
• 
  FIGNT

  2019-10-28

  对层级的依赖倒置不太理解。好像还有个防腐层的概念。不知道能解释下吗

  作者回复: 依赖倒置举个例子，领域层是通过仓储接口获取基础资源的数据对象，仓储接口会调用仓储实现，具体的基础资源的数据处理过程是在仓储实现中完成的。这样做的好处是，避免将仓储实现的代码混入上层业务逻辑中。如果以后替换数据库，由于做了基础资源的个性的代码隔离，所以实现了应用逻辑与基础资源的解耦。在更换数据库时只需要更换仓储相关的代码就可以了，应用的逻辑不会受太大的影响。 防腐层我感觉主要是实现新旧系统切换时，出现业务逻辑混杂在一起的情况，避免污染领域模型的实现逻辑。因此增加防腐层隔离旧系统对领域模型的影响。在完成新旧切换后，防腐层的代码就可以抛弃不用了。

  共 7 条评论

  4
• 
  Geek_73f7d7

  2020-06-27

  老师你好，最近公司再做智能手环相关产品，由于手环品类多，各大厂商的协议也不能，每次都需要针对新的手环开发新的web产品，但是他们的功能都大致一样，目前是把权限管理作为边界，抽出了一个微服务，前端也用了组件化达到复用，那么针对设备管理，或者对接这块，老师有没有好的建议，期待老师回复

  作者回复: 你这一块可以开发一个微服务，然后用用户接口层来适配不同的前端数据和接口需求。 在微服务面向不同前端应用时，同样的一段业务逻辑，可能由于渠道不同，而在前端展示的页面要素不同，因此要求后端微服务返回的数据结果会不同，需要的接口协议可能也不一样。 这时用户接口层的Facade服务和数据组装器Assembler就可以发挥作用了。Facade服务可以封装应用服务，数据组装器Assembler可以根据不同前端应用的数据需求，完成前端DTO和后端DO对象的组装和转换等操作。面向不同前端应用提供不同的Facade接口和DTO数据服务。这样，我们不需要调整任何后端服务，就可以面向不同的前端应用，提供灵活的接口定制和数据适配服务了。

  共 2 条评论

  3
• 
  鲲哥

  2019-12-08

  欧老师，你好。问一个具体实现上的问题。充血模型的实体如果需要持久化，是直接调用repository还是由领域服务调用？如果直接调用，那在spring是如何实现的呢？sprign中repository一般单例bean,充血应该不是单例吧？那他是如何依赖repository的呢？

  作者回复: 一般都是通过应用服务或者领域服务来完成仓储调用，实体或聚合根作为参数传入仓储接口，通过仓储实现来完成持久化。一个简单的例子如下： public class OrderService { private OrderRepository orderRepository; public Order updateOrder(order) { ***； orderRepository.save(order); ***； } }

  共 2 条评论

  3
• 
  瓜瓜

  2019-11-13

  作者回复: 依赖倒置后基础层就通过仓储接口获取外部参数了，然后根据这些业务参数完成基础逻辑的实现，这个实现是在基础层。不采用依赖倒置的传统四层架构，基础层和业务逻辑实现可能会在应用层或领域层，两者逻辑混杂，不利于解耦。 老师您好 基础层通过仓储接口过去外部参数，这句话不是很懂，基础层的逻辑，哪些属于基础层逻辑呢？比如根据do的不同状态决定是否存库或者是否发送到消息总线中，是否是指这一类逻辑？还有，是不是领域层（或者是应用层）的对象do和仓储层对象po的转换发生在仓储层，还是仓储层传给基础层的实体就是do而不是po？do还po的转换应该放在哪里？ 根据依赖倒置的原理，感觉基础层暴露给应用层和领域层的仓储层中的接口参数是do（领域实体），而不是po，不知道理解的对不对，望老师解答，感谢感谢感谢 还有您说的如果采用传统的四层架构，基础层以及基础层业务逻辑实现就会耦合在应用层或领域层，是不是就是上面说的根据不同的状态做不同处理的逻辑，还有没有其他常见的逻辑？感谢老师

  展开

  作者回复: 基础层的逻辑主要是SQL代码，DO和PO的转换和映射以及数据的持久化等。在没有仓储之前，这些代码会跟业务逻辑混杂在一起的。 领域层和应用层通过仓储接口会将DO的对象传给仓储实现，在仓储实现里面实现DO和PO的转换以及数据的持久化。 初始化的时候，仓储实现会实现PO到DO的转换，然后返回DO对象。 这样的话，业务逻辑都是基于DO的操作，不管基础层如何变化，只要DO不发生变化，业务逻辑都不会影响。这样就实现了业务逻辑与基础逻辑的解耦了。 仓储给你看一段在答疑那一节里面代码。 有Person聚合根，Person仓储接口和仓储实现。 /** * Person聚合根 */ public class Person{ private String id; private String name; private int age; private boolean gender； } /** * Person仓储接口 */ public interface PersonRepositoryInterface { void save(Person person); void delete(String id); } /** *Person仓储实现 */ @Repository public class PersonRepositoryImp implements PersonRepositoryInterface { private PersonMapper mapper; public void save( Person person) { mapper.create(person); } public void delete((String id) { mapper.delete(id); } } 在应用逻辑中直接用仓储的接口就可以了，数据库相关的逻辑在PersonMapper里面实现。 PersonRepositoryInterface personRepos; personRepos.save(person)

  共 3 条评论

  4
• 
  香

  2020-12-13

  有这样一个问题需要请教一下老师。 在我的实际场景中有这样一个微服务，它就是用来转调各个微服务来组装数据返回给前端页面的。 如果采用DDD的设计理念，我的想法是这样： 1.首先它就是个转调的服务，没有核心逻辑业务而言，所以分层应该只有用户接口层、应用层和基础层； 2.在应用层调用其它微服务接口，完成数据的组装后交由给用户接口层； 我的问题是： 1.我的这样设计有没有问题？ 2.在应用层调用其它微服务时，它需要用到一些Rest调用的组件或客户端，那么这些Rest调用的客户端是放在应用层本身还是基础层？还是？ 3.看到老师回答的一些问题提到DTO到DO对象的转换的说明，但都是建立在有领域层的场景，在我的场景中，没有领域层，那么我理解就不存在所谓的DO对象，这种转换要如何处理，就是当我通过用户接口层去调用应用层的应用服务方法时，在我的应用服务里，我的方法参数该如何设计？ 说实话感觉这一讲如果能结合着一个小demo，就是有一份简单的小代码架构会比较好理解的。 另外我还有一个疑问就是： 4.在每一层都需要做一个对象的转换，这样我理解是不是会产生太多的这种冗余代码了？因为我看到这一讲的时候还有大家的提问，我脑海里满是各种对象的translate。

  展开

  作者回复: 你这个微服务的功能就是BFF微服务的功能呀。下面一章会讲到。 BFF微服务只有应用层和用户接口层的职能，完成各个微服务的服务组合和编排，适配不同前端和渠道应用的个性需求，为前端应用提供粗粒度的组合服务。所以它没有领域模型，也不会有领域层，它不需要实现领域逻辑。BFF微服务与应用服务的差异主要体现在：BFF主要是微服务之间的服务组合和编排，而应用服务主要是微服务内的服务组合和编排。 您说的对象转换需要按需设计，如果不需要做各层的解耦的话，就不需要定义那么多的DO对象了，也就不需要转换了，毕竟转换也有性能损耗。

  共 2 条评论

  2
• 
  沈

  2020-09-09

  老师，.领域层可以依赖基础层，而基础层不能依赖领域层，那领域层的repo如何调用基础层的dao进行落库呢？

  作者回复: 基础层可以面向所有层提供服务。其它层通过repo接口来访问基础层数据处理实现逻辑。这里采用了仓储模式。仓储模式包含仓储接口和仓储实现，仓储接口面向领域层提供基础层数据处理相关的访问接口，仓储实现完成仓储接口对应的数据持久化相关的逻辑处理。 领域层业务逻辑面向仓储接口编程，当聚合内的实体数据需要持久化时，只需将领域对象DO对象转换成PO持久化对象，然后传递给仓储接口，通过仓储实现完成DO数据的持久化工作。这样领域层就可以更好的聚焦于聚合的领域逻辑，而不必关心实体数据在基础层到底是如何实现持久化的了。 当更换数据库等基础资源时，我们只需要调整仓储实现代码，做好仓储实现的数据持久化处理逻辑与新数据库的适配就可以了。由于领域逻辑只通过仓储接口访问基础层实现逻辑，所以在更换基础资源时，只要仓储接口不变就不会影响到领域层的任何领域逻辑。 这是一种依赖倒置的设计方式，业务逻辑面向接口编程，而不是面向实现编程。这样可以避免业务逻辑与实现逻辑的耦合，在实现逻辑出现变化时，降低对业务逻辑的影响。

  共 3 条评论

  2
• 
  Tesla

  2020-02-06

  老师好，现在大多数orm框架都支持多RDBMS，只需要简单配置就能实现mysql到mssql的替换。那还需要依赖倒置吗？

  作者回复: 能做到依赖分离，就不必要了。

  共 3 条评论

  2