答疑：有关3个典型问题的讲解
讲述：欧创新
时长11:03大小7.60M
精选留言(13)
2019-11-06事件风暴？为什么一有关键词总会出现这个，它不就是一个集中讨论定需求的动作？陌生词汇太多，如果夹杂一些白话最好了，感觉这一套字眼真的是越说越迷糊了，DDD 我感觉说白了就是一种划分手段，核心最终都会落在为服务上展开 4
2019-11-06老师，实体内可以调用他所在聚合的仓储吗？展开作者回复: 一般通过聚合根来做。
2
2019-11-06事件总线 实现思路？用到什么技术或来源组件？还是说事件总线就是消息队列呢作者回复: 事件总线就是一个带发布和监听功能的jar包，直接跟你的微服务代码放一起就行了，它属于基础层的代码。提的比较多的是EventBus。你可以去网上找找资料。
2 2
2019-11-06您好，领域层提供仓储接口，基础层实现仓储接口，依赖倒置的设计是非常好的，能够拆除领域层对基础层的依赖。
上层向下依赖领域层，领域层通过依赖倒置，让基础层也依赖领域层，这样就实现了领域层为核心的设计理念。
领域驱动设计提出了全新的设计思路，讲述偏抽象，重点在如何落地，期待实战篇。展开 3 2
2019-11-07基础层依赖领域层。能录个例子吗？如何反转依赖的，还是不明白作者回复: 一个非常简单的例子，有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) 1 1- 2019-11-11仓储层跟传统的dao层感觉没啥区别？展开
作者回复: 仓储只是一种应用和数据库解耦的手段，它是一种手段和方法，传统架构也是可以用的。
2019-11-07使用充血模型，比如RPC的接口包，接口包的实体为充血模型，该实体的很多功能需要引用很多第三方jar包，这样会不会导致接口包很沉重，比如说一个图片上传服务，客户端和服务端交互是通过图片实体来进行交互的，而图片的下载和上传是属于图片实体的内部功能，这样图片实体就会引用apahce.httpclient的很多jar包，该怎样解决这个问题呢展开作者回复: 你这种方式可能就不适合充血模型了。
DDD用充血模型的主要目的是为了在领域模型中体现实体的业务行为，而不是所有实体的行为混杂在一起。但是这只是一个建议的设计原则，贫血模型有时候也是不可避免的。- 2019-11-07微服务内不使用事件总线，如何保证两个聚合操作的一致性？
作者回复: 这个需要权衡，看看引入事件总线后，这个复杂度可不可以接受。通过应用服务加事务机制应该也可以解决，在同一个进程内的事务应该比跨微服务的事务相对来说还是好控制，对性能影响也会小一些吧。
2019-11-07老师，您好！有一些设计实现上的疑问：
领域服务的CRUD是不是都是操作聚合根或整个实体对象，比如我只想根据ID判断记录是否存在，或者返回个别字段，需要返回整个实体对象吗？作者回复: 其实查询类业务可以不必经过聚合根和仓储。传统方法也可以了。
如果聚合数据比较多，会有延迟加载影响性能。
聚合根的主要目的是为了保证数据的一致性，这些场景一般在CU的场景。- 2019-11-06工厂创建出实体或者是聚合跟之后再加到仓储中吗(持久化)？
作者回复: 创建完后会初始化数据，变更后的数据会通过仓储持久化。
2019-11-06之前提过这个问题，基础依赖领域的仓储接口，领域不还得依赖基础层的通用组件吗？这不循环依赖了吗。作者回复: 用仓储的目的是为了隔离相互影响。
你说的这种情况我理解是从哪里调仓储接口的问题吧，比如一个基础层组件A依赖领域层，另一个基础层组件B，依赖基础层组件A，然后B只能从领域层仓储接口调A的接口，不知道理解的对不对哈？
其实在微服务内只要你能够做好代码逻辑隔离，仓储接口放哪里都无所谓。
这样设计只是考虑大部分的情况，为了让代码更清晰一些，毕竟大部分的数据仓储的服务都是从领域层发起的。- 2019-11-06讲的很精简，把《实现领域驱动设计》的主要内容讲的很清楚了。但是还是很抽象的，关键还是要实战，加深理解展开
2019-11-06感觉有点像，设计模式中核心的一句话。封装变化。变化是无穷的，但是我们尽可能的把，变化引起的改动降到最小。展开
