精选留言(71)

• 
  伊来温

  2020-07-02

  我的回复怎么不见了，再发一下。请教下老师，关于领域代码的分层和编排上一直以来我有个一个疑问。假设我有两个领域聚合跟，用户(User)和企业(Corp)，对应的领域服务是UserDomianService和CorpDomainService，那我假如需要这个一个接口listCoprUser来获取企业下面的用户列表， 这个接口该放在哪一层做编排呢。1. 如果放在CorpDomainService里面，则会造成对User实体的引用，造成耦合。2.难道上升到app层做编排么？但listCoprUser又像是一个领域服务。3.又或者做成一个新的领域服务CorpUserDomainService吗？那是不是CorpUserDomainService在代码结构上只有一个领域服务，而没有repository, domain层级了呢？

  展开

  作者回复: 从你的场景来看，企业跟用户是一对多的关系吧。你可以这样设计，在企业聚合中将用户的相关信息设计为一个包含若干用户属性的用户值对象，然后企业聚合根引用用户值对象，用户值对象的数据来源于用户聚合。 用户聚合包含了全量的用户数据，而在企业聚合中用户值对象只是简单必须的用户数据，通过这种数据冗余的方式，在企业聚合中，就可以通过企业领域服务中一次获取企业和它相关的用户数据清单。

  共 13 条评论

  24
• 
  Jack.Chen

  2019-12-30

  希望把完整样例代码放出来

  作者回复: 这两天会加一篇完整的代码详解。

  共 6 条评论

  16
• 
  冯磊

  2020-06-29

  感觉application这一层完全可以去掉，intrerface直接调domain service就可以的。作者能解释一下application这一层为什么必须存在吗？

  作者回复: 应用层连接用户接口层和领域层，它是很薄的一层，主要职能是协调领域层多个聚合完成服务的组合和编排。 应用层之下是领域层，领域层是由多个业务职责单一的聚合构成，实现核心的领域逻辑。应用层负责协调领域层多个聚合的领域服务或领域对象，面向用例和业务流程完成服务的组合和编排。所以理论上应用层不应该实现领域模型的领域逻辑。这也是应用层为什么会很薄的原因。 应用层之上是用户接口层，在应用层完成领域层服务组合和编排后，应用服务被用户接口层Facade服务封装，完成接口和数据适配后，以粗粒度的服务通过API网关面向前端应用发布。 此外，应用层也是微服务之间服务调用的通道，微服务在应用层可以调用其他微服务的应用服务，完成微服务之间的服务组合和编排。 在应用层主要有应用服务、事件订阅和发布等相关代码逻辑。 其中，应用服务主要负责服务的组合、编排和转发，处理业务用例的执行顺序以及结果的拼装。在应用服务中还可以进行安全认证、权限校验、事务控制、领域事件发布或订阅等。

  共 4 条评论

  13
• 
  suke

  2020-06-27

  老师 请问依赖倒置是如何体现的？还有所谓的充血模式，最好能有具体的代码说明，不然还是觉得很空洞

  作者回复: 依赖倒置的代码在加餐里面会有详细说明。 一、依赖倒置（DIP）设计：是指面向接口编程，而不是面向实现编程。这样可以避免业务逻辑与实现逻辑的耦合，在实现逻辑出现变化时，降低对业务逻辑的影响。 为了解耦领域逻辑和数据处理逻辑，我们在领域层和基础层之间增加了薄薄的一层，这一层就是仓储。 仓储模式包含仓储接口和仓储实现，仓储接口面向领域层提供基础层数据处理相关的访问接口，仓储实现完成仓储接口对应的数据持久化相关的逻辑处理。一个聚合会有一个仓储，统一由仓储来完成聚合数据的持久化。 领域层业务逻辑面向仓储接口编程，当聚合内的实体数据需要持久化时，只需将领域对象DO对象转换成PO持久化对象，然后传递给仓储接口，通过仓储实现完成DO数据的持久化工作。这样领域层就可以更好的聚焦于聚合的领域逻辑，而不必关心实体数据在基础层到底是如何实现持久化的了。 仓储接口的实现逻辑非常简单，只需要在仓储接口类中，定义仓储实现的基本接口和参数就可以了。 仓储接口代码如下： public interface PersonRepository { void insert(PersonPO personPO); void update(PersonPO personPO); PersonPO findById(String personId); PersonPO findLeaderByPersonId(String personId); } 仓储实现会根据仓储接口的数据处理逻辑要求，调用DAO完成数据查询或数据持久化，如基于聚合根ID的查询，聚合中新增或修改等领域对象数据的持久化操作。假如数据库需要技术升级，我们只需调整仓储实现的数据处理逻辑，适配新的数据库就可以了，这种调整不会影响领域逻辑。 仓储实现代码如下： public class PersonRepositoryImpl implements PersonRepository { @Autowired PersonDao personDao; @Override public void insert(PersonPO personPO) { personDao.save(personPO); } @Override public void update(PersonPO personPO) { personDao.save(personPO); } @Override public PersonPO findById(String personId) { return personDao.findById(personId).orElseThrow(() -> new RuntimeException("未找到用户")); } @Override public PersonPO findLeaderByPersonId(String personId) { return personDao.findLeaderByPersonId(personId); } } 在领域服务中，可以调用仓储接口完成数据持久化操作。由于领域服务只与仓储接口发生调用关系，数据的持久化逻辑在仓储实现中完成。因此在更换数据库时，只要仓储接口不变，领域服务的逻辑就可以一直保持不变。 领域服务如下： public class PersonDomainService { @Autowired PersonRepository personRepository; public void update(Person person) { personRepository.update(personFactory.createPersonPO(person)); } } 这样就保持了领域层领域逻辑的稳定，实现了领域层与基础层的解耦和依赖倒置。 二、充血模型与贫血模型的关键差异： 在充血模型中，业务逻辑都在领域实体对象中实现，实体本身不仅包含了属性，还包含了它的业务行为。DDD领域模型中实体是一个具有业务行为和逻辑的对象。 而在贫血模型中领域对象大多只有setter和getter方法，业务逻辑统一放在业务逻辑层实现，而不是在领域对象中实现。

  共 4 条评论

  12
• 
  ANYI

  2019-11-15

  1，对于实体采用充血模型，包含自己的属性及行为，例如保持、更新、删除等行为方法，需要持久化，依赖基础层数据库操作，是在实体直接引入，例如mybatis的mapper？ 2，对于相对简单的实体操作增删改查这种，需要暴露到接口层；那要一层一层向上封装，实体》领域服务》应用服务》接口服务；这样是不是又显得代码很多余；一个简单的增加修改方法接口，需要很多冗余代码，上层也没有其他逻辑，封装一下调用下层，写一个接口，要写很多层次调用，是否会很臃肿啰嗦，是不是就可以直接接口层封装就省去一些层呢？ 3，在服务编排上有没有一些框架什么的？还是都是通过if else的手写？

  展开

  作者回复: 1、实体的这些数据库映射是通过mapper来实现的。 2、松散分层架构是可以跨层调用了，实现起来很容易。但是在复杂的情况下，服务不太容易管理，比如，你可能不知道你的方法到底被谁组合和封装了，一旦出现方法变更，你不容易一次找出所有受影响方。而逐层封装的话，你只需要逐层通知到上层就可以了。 3、微服务内的服务编排相对简单，就是业务逻辑的执行顺序而已，个人感觉不需要引入什么工具。

  共 7 条评论

  5
• 
  Jxin

  2019-11-15

  1.同求代码案例。（基于一个非ddd微服务的demo，分支形式实现微服务内部代码规范，跨服务间代码重组） 2.代码案例这个成本很大，但还是厚颜无耻的提了。毕竟缺少代码这个实体，这个专栏感觉就少点东西。毕竟讲得再抽象精准，可能也没有展示code来得直接明了。 3.我们需要从实悟虚，从虚就实。如果理论能结合code案例，这个专栏的学习成本和实用性将会有质得飞跃。

  展开

  作者回复: 谢谢你的建议。后面准备准备，可能需要点时间。

  

  5
• 
  日月星辰

  2020-06-02

  同一个微服务里不同领域之间的调用可以在应用层直接调用吗？

  作者回复: 同一个微服务不同聚合之间为了解耦，不建议聚合之间直接调用。你可以将聚合之间的调用提升到应用层，通过应用服务来实现跨聚合的组合和调用。

  

  4
• 
  吴海洋

  2019-11-15

  写得不错，通俗易懂。文章结构也符合我的阅读习惯。👍

  

  4
• 
  Peter Yu

  2020-11-26

  老师，aDomainService何以调用bDomainService的方法吗。比如之前有个同学提问：Corp和User属于两个领域，但是Corp中有个查询user的服务，你建议他将此方法放在domainService层，那同步user的数据时，corpDomainService岂不是得调用userDomainService了？

  作者回复: 聚合之间的领域服务是不建议相互调用的，这样聚合之间会产生耦合，不利于未来领域模型演进和聚合的拆分。聚合之间有两种协作模式，一种是领域事件驱动的模式，可以实现聚合之间数据的传输，另外一种是在应用层通过应用服务来组合和协调不同聚合的领域服务，完成跨聚合的调用和操作。

  

  3
• 
  Geek_deb968

  2020-03-28

  大部分业务场景其实都是查询的比较多，关于领域模型我现在看到的和理解到的都是实体简单业务操作，我十分希望能看到关于查询在DDD上代码是怎么实现的，比如门店是一个聚合根，门店菜系设计为值对象，那么我根据菜系查询门店是不是在领域模型上很难操作了，感觉领域模型都是在实体也就是满足确定了唯一标识的情况下，才能发挥作用，动态的查询在DDD上是需要怎样实现呢

  作者回复: 复杂的查询一般都不走领域模型，一般这种查询你可以用原来的查询设计方式，或者采用读写分离方式。在DDD领域模型中主要是基于聚合根的id的查询。

  共 3 条评论

  3
• 
  峰

  2020-03-21

  如何识别出聚合根？

  作者回复: 一个参考是聚合中的关键实体，另外可以根据引用关系来判断，在所有具有引用关系的实体或值对象中，处于根位置的就是聚合根。

  

  3
• 
  Jesen

  2019-11-29

  老师，如果把仓储Respository的实现放到基础设施层，其仓储接口定义在领域层里面，那么在领域层里面该怎么持久化呢，可以通过在应用层中将仓储注入到领域服务里面来实现吗？

  作者回复: 这个只是代码存放目录的考虑。具体的持久化是在仓储实现的服务里面。为了方便聚合的重新组合，我在代码目录结构里面将仓储的接口和实现都放在领域层的聚合目录下，如果微服务架构演进，你可以直接将聚合相关的代码一起拿走。

  

  2
• 
  徐李

  2021-12-20

  这样的一个微服务设计过程，在几十万，几百万行的代码系统中，不是要维护很大很大一个映射关系吗？基本上是每一个类，每一个操作，现在的接口都是要映射成DDD对应的实体，事件模型等对应名词。

  

  1
• 
  Peter Yu

  2021-07-19

  老师，我在ddd实际中遇到一个非常困惑的问题。我有个服务是实现代码质量分析的。现在分析数据在表里都有了，主要有一张DailyMeasure表，记录date（日期），author（开发人员），metric（度量单位：如提交数commits、有效代码行书validCodeLines、sonar问题数issues等），value（度量的值）。【相应的领域对象也是这些字段】。 现在我有一个报表功能，主要是分页展示每个用户指定日期时段内的度量数据AuthorMeasures（authorId、duplicatonLines、validCodeLines、validCommentLines、issues、commits）。这个对象没有任何业务，只要聚合DailyMeasure表的数据返回给前端即可。 按传统写法只要写个sql封装成AuthorMeasuresDto就回传给前端可以了。但按照ddd思想，还得要建do、po，然后在各个层转化一遍，多了许多刻板流程（repositoy->po->factory->do->domainSerive->applicationService->assembler->dto）。我想问的是，对于没有业务逻辑的查询，也得严格遵循ddd的代码范式吗，感觉非常冗余和臃肿。 望解惑！

  展开

  共 4 条评论

  1
• 
  有爱有波哥

  2020-11-11

  老师说的在DDD领域模型中主要是基于聚合根的id的查询，这个不理解，那复杂查询怎么设计，能给点建议和思路吗

  作者回复: 复杂查询不放在领域模型内。你可以用CQRS模型，也就是读写分离模式，将复杂的读模型分离出去，形成读和写两个不同的聚合，读模型可以面向整个微服务提供服务。这样复杂的查询就可以自由的采用SQL获取复杂的数据关联，如跨聚合查询等。读模型和写模型可以共享一个数据库，也可以采用读写数据库分离的方式来实现。

  

  1
• 
  Even He

  2020-11-03

  老师您好。想请教一个问题。 例子中，遵循了严格的分层方式，即不允许跨层调用。如appService需要调用entity的方法需要通过domainService。（虽然我觉得appService调entity也不算跨层，理由是application层和domain层中间没有其他的层。） 那interface中的assembler，它的职责是将dto转化成domain object。这个处理如果实在interface种执行，是不是变成了跨层调用？ 期待您的回复。谢谢。

  展开

  作者回复: appService是在应用层，entity的方法是在领域层，虽然它们都在同一个微服务，中间还有领域服务，因此属于从应用层到领域层的跨层调用。如果应用层直接访问entity的话，部分领域逻辑就会落到应用服务中，如果应用服务组合了多个聚合的实体，就容易使得聚合之间产生耦合，甚至直接对不同聚合实体对象的访问，会破坏领域层聚合内部的业务规则控制逻辑。记住，应用服务主要是完成服务组合和编排，以及协同的工作，基本不参与聚合内部的领域逻辑。 而interface中的assembler职责主要是完成对象之间的转换操作，这部分内容不涉及服务调用和业务逻辑处理。

  

  1
• 
  一两

  2020-10-26

  老师，聚合或实体可以直接调用仓储接口吗？为什么网上有的说法是仓储接口应该在应用层调用，感觉应用层调用仓储接口的话，难免会把业务逻辑拆的四分五裂把

  作者回复: 是的，仓储一般都是跟聚合是一对一的。应用层服务主要是做服务组合和编排，一般不会直接和数据打交道。但是也有特殊的情况，比如在应用层完成查询逻辑，或者跨聚合的复杂查询，而这些逻辑一般不会有领域模型的概念。

  

  1
• 
  赵宇浩

  2020-02-10

  问题一: 假如用户是个复杂聚合根，同时存在List的操作一般怎么处理。 比如支持单用户信息创建以及批量用户信息创建。 单用户的实体创建包含基本信息校验和仓储写入两个步骤。 但批量创建不太可能循环调用每个用户的创建方法吧。 所以这样就要给用户这个类再加个基本信息校验的方法？ 然后领域服务层，循环校验之后，再批量写入？ 但这样用户这个类，就要有两个构造方法？ 一个需要持有仓储(单用户操作)， 一个不需要持有仓储(用于多用户操作)？ 问题二: 比如用户里包含了地址和账户。 那么仓储的事务怎么考虑，事务也由用户这个类去保证么？还是事务在领域服务里实现？ 实现一:在用户实体里持有用户仓储，账户实体里持有账户仓储，然后用户创建的方法里，先调用账户的写入方法，再调用自己的仓储保存，如果自己存储失败，回滚？听上去好像可以实现，也符合逻辑。但是感觉这个类的每次实例初始化是不是有点麻烦。 实现二:实体不持有仓储，领域服务是单例的，就可以直接注入用户，账户，地址的仓储，然后只是组装内存数据，在领域服务层依次调用仓储，保证事务。也可以实现，但这样实体的责任是不是太弱了，这个领域服务层和三层架构的service层是不是有点像。 不知道实际中怎么做更推荐，望指导

  展开

  作者回复: 第一个问题：如果这种复杂的批量处理的数据导入或者数据查询，没有很强的业务规则或者数据一致性要求，你可以直接在应用层通过应用服务完成批量导入或者查询就可以了，不需要经过领域层。 第二个问题：我理解是跨用户、地址和账户的多个聚合的事务一致性要求。你可以通过事件总线，一次修改一个聚合，其它聚合的数据修改通过领域事件机制异步处理，采用数据最终一致性的方式。或者在应用服务中处理这三个聚合数据修改时采用分布式事务处理机制也是可以的。

  共 4 条评论

  1
• 
  okjesse

  2020-02-05

  【如果一个业务动作或行为跨多个实体，我们就需要设计领域服务】，请问这个实体指的是一个聚合根下面的多个实体吗。 我看例子代码也是一个聚合根会有一个领域服务，会存在一个领域服务跨多个聚合根吗。

  作者回复: 领域服务只在一个聚合内，一般不建议跨聚合的领域服务调用，这样会增加聚合之间的耦合度，不利于架构演进时微服务的再次拆分。 领域服务只是针对一个聚合内的实体。

  

  1
• 
  蚂蚁内推+v

  2020-01-29

  想问下实体的增删改查是由实体来做还是领域服务来做？谁来调用仓储

  作者回复: 实体自身的方法来完成增删改，复杂查询可以交由应用服务来做。仓储接口可以在应用服务或者领域服务中调用，也可以是聚合根的方法里。

  

  1