答疑：有关3个典型问题的讲解

作者回复: 一个非常简单的例子，有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)

作者回复: 感谢，写的很好。

作者回复: 是的。依赖倒置的定义就是面向接口编程，这样不同层之间的服务在实现逻辑发生变化的时候，就不会相互影响了。

作者回复: 其实查询类业务可以不必经过聚合根和仓储。传统方法也可以了。 如果聚合数据比较多，会有延迟加载影响性能。 聚合根的主要目的是为了保证数据的一致性，这些场景一般在CU的场景。

作者回复: 一般通过聚合根来做。

作者回复: 先只从领域建模的角度来说优势吧。因为DDD是一种面向对象的编程方式，采用充血模型，每个实体就会有自己的业务行为，在领域模型设计时，每一个实体除了自己的属性外，还会有自己的业务行为，而不会将所有的业务逻辑放到业务逻辑层。这样就有利于实体、聚合的解耦。当你需要进行再次拆分的时候，就会很容易。

作者回复: 事件总线就是一个带发布和监听功能的jar包，直接跟你的微服务代码放一起就行了，它属于基础层的代码。提的比较多的是EventBus。你可以去网上找找资料。

作者回复: 这个需要权衡，看看引入事件总线后，这个复杂度可不可以接受。通过应用服务加事务机制应该也可以解决，在同一个进程内的事务应该比跨微服务的事务相对来说还是好控制，对性能影响也会小一些吧。

作者回复: 领域太大的话，建议先划分子域。这是因为领域太大，不好开展事件风暴。在将领域划分成合适大小的子域后，进行事件风暴完成领域建模就比较容易了。

作者回复: 是的。