06 | 跨越现实的障碍（下）：架构分层就对了吗？

理论指导实践，实践反哺理论，有时实践对了但归纳不出理论，有时有了理论却落不了地，统称摸着石头过河，这是低手所为，高手总是深刻理解理论，升华理论，实践手到擒来，行云流水 使用maven构建项目时，根据DDD拆分成四个module并如此依赖：controller -> application -> domain -> infrastructure 但存在一个循环依赖问题：ddd中规定repository是domain,所以接口在domain层，但现实在infra层，那infra得依赖domain了，可从maven module依赖讲，domain是依赖infra的，只能先把repository接口放到infra中 可domain才是核心，最稳定的，不能被技术束缚，倒置一下，但技术并不只有db，还有IO,消息等等总不能像repository一样，把这些接口都放到domain，那domain很不纯粹 聪明的我又想到用namespace解决，从maven module讲，这些都放在domain层，但不再放在com.zhuxingsheng.domain包下，而放到对应的包下，如message放在com.zhuxingsheng.message，这样保证了domain的稳定，落地也不太别扭 这样好不好，不知道，至少说服我自己了 相比老师的能力供应商模式，差了好几个层次，第一只关注技术，没有对接口提取出领域概念，以领域知识为核心，第二虽然觉两层关系有丝丝别扭，但不敢质疑，并大声说出他们关系的不正当

1.能力供应商/防腐层，其实都是一个东西。为逻辑功能的组成部分定义清晰的业务模型 + 领域层只包含自身定义的业务模型（接口/类） + 为这些业务模型定义寻找实现。隔离变化，不管是不同变化频率还是不同变化方向。 2.双向依赖大部分时候，可能是领域模型有所欠缺。识别定义抽取新的领域模型来公用会比实现双向依赖要好些，哪怕双向是隐式的，如果时间允许的话。 课后题，太晚了，脑子思绪混乱，等周末再琢磨。

为什么说支付失败的回访是应用层逻辑，而不是领域层逻辑呢，这里的划分是有什么准则吗

思考题，根据前面说的两关联一循环。这里把技术概念转换成了领域概念，然后反映到统一语言上。这就需要团队不断的执行循环，才能把知识消掉。业务方和技术方也需要紧密的配合和互相信任。

看到这章对老师膜拜了。看过不少DDD的内容，实际很难落地，老师结合软件设计相关内容从更高的纬度指导落地，这正是我想要的。

用拟人化去命名这个很妙！另外文章中的例子，实际设计中应该会丟一个消息中间件作为解耦。例如业务要发消息，发邮件，这样是不是就减少对基础设施的依赖？

文中能力供应商的实现方式是方法中传入，想必应该是在能接触到能力供应商的实例的最初始的调用者上传入的，比如领域服务。那么问题来了，在较为复杂的调用链中，这种传来传去很奇怪，该如何优化及避免？

老师你好，为什么失败回访是应用层的逻辑而不是领域层的逻辑呢？如何区别？比如业务需要记录一下回访的次数是不是就变成领域逻辑了？

“不正当关系”😂。写的太好玩了

DDD本身有所谓的成熟度模型吗？比如总共有5档，有些项目可以做到5，有些项目受限于某些因素只能做到2或者3。这样的成熟度模型是否有意义