低欲望，日本病

建议把 domain 层单独做一个模块，几乎不添加外部依赖，让其他模块都去依赖 domain 层

@shuanglinzui 暂时不招，经济不好

2017 年开始用，一直用到现在 95%的后端都切到 kotlin 了

git flow 太啰嗦了，TDD 做得到位结合 Feature Flag 用 MainLine 模式最好了

如果架构足够整洁，可以让领域层的业务逻辑代码完全跟外部依赖(其他服务和数据库，MQ 等)解耦

真正的测试驱动开发，是可以利用测试用例一步步推演出代码实现的，比正常写代码更快
感兴趣的可以参阅《匠艺整洁之道》或者极客时间上找找测试驱动开发的课程
另外 ATDD 和 UTDD 是两种不同的模式，要根据工程业务复杂度和实际情况选择占比，通常来说如果业务非常复杂我更推荐 UTDD ，可以大幅加快开发实现速度

很多人觉得写测试做 TDD 会延迟交付。。。其实恰恰相反，就算不考虑自动化测试带来的长期价值，哪怕只是一次性的也比正常写代码更快。前提是架构足够整洁，易于测试，和开发人员知道怎么写真正跟实现解耦的测试。
所以 TDD 要真正落地并不容易，往往需要团队里有真正懂这个的 Teach Leader 来负责

没有任何意义。。。封装不是这么用的 2333

@BrightLiao 嗯，是这个道理，我也很热衷用 UTDD 驱动代码和模型成型，因为我有测试覆盖强迫症，被 UTDD 驱动出来的代码天然就双 100%覆盖了，不用后面再去补。但是这个跟聚合不矛盾，没有聚合的情况下，面对成群的领域对象，如何管理对象之间的依赖关系呢，稍不注意就可能形成复杂的对象网？

@BrightLiao TDD 可以实现所有程序，前提是 use case 很明确了。但是在概念建模和领域建模的时候，往往用例也还不是那么的明确，很多东西需要跟领域专家一起从模型层面推导出来。聚合还有一点就是可以约束领域对象之间和控制器与领域对象之间的依赖关系。防止形成过于复杂的对象网

@BrightLiao 如何划分聚合有一整套原则和操作指南，《解构领域驱动设计》里面有详细介绍。
总的来说就是先判断关系，泛化和物理包容关系的先无脑划分到一个聚合里面，其他的关系一律隔离开，然后再做微调去拆分过大的聚合。如何判断是否过大有经验和子实体是否有一定的独立生命周期来判断
通过聚合来测试我个人实践下来是非常好用的，没有遇到什么麻烦，可能我的聚合力度不是太大也有关系吧。话说回来，微服务架构其实单测我写的不多，验收测试写的更多，少数核心业务逻辑可能会用 UTDD 来做和验收测试比较难覆盖的分支才会用单测弥补。
可以参考这个 https://insights.thoughtworks.cn/test-pyramid/

@BrightLiao 《解构领域驱动设计》里面有详细介绍菱形对称架构，我觉得很好，非常符合 整洁架构的思想，也就是外层技术机制，应用业务规则都去依赖 核心领域实体。 核心的 domian 层没有任何外部依赖，这一点 Smart Domain 也做到。不过 Service,Repository 姑且不论。我坚持认为 Aggregate 是必须的，这是让领域对象可测试可管理可解耦的关键。就拿测试来说，如果针对每个领域对象一对一的写测试，那么测试代码就会跟被测试的代码高度耦合，模型层的任何调整都可能引起大量测试失败。只针对聚合根的行为去编写测试就可以对聚合根之外的对象有效解耦

很不错的尝试值得参考，未来考虑在一些新项目里小范围尝试
目前还是主要用 菱形对称架构 除了有点重，其他都感觉很好

不会可以学。。

当你为了集体无私奉献的时候一定有人在不劳而获

DDD 棱形对称架构
分层 或者 每个层里面不同类型的对象需要很强的约束，只承担自己应该承担的职责绝不多做半点事，这需要团队有很强力的 code review 机制才能做到

用 DDD 就是 OOP