V2EX › yule111222 的所有回复 › 第 5 页 / 共 7 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7

❮

❯

2022-10-11 08:54:02 +08:00

回复了 17lian 创建的主题 › 程序员 › 我用自己理解的领域驱动设计，写了一个基础开发平台，本着学习的心态和大家分享，欢迎大家提供意见或建议

@brucetao2009 单独的 maven module,从依赖关系上彻底隔绝向外依赖的可能性

2022-10-11 08:52:37 +08:00

回复了 kerrspace 创建的主题 › 程序员 › 如何跨越 coding 菜鸟到老手的鸿沟

看不懂就不是好代码，C++的历史包袱而已

2022-09-30 17:20:13 +08:00

回复了 chniccs 创建的主题 › 问与答 › 为什么没有欲望了

低欲望，日本病

2022-09-30 14:44:36 +08:00

回复了 17lian 创建的主题 › 程序员 › 我用自己理解的领域驱动设计，写了一个基础开发平台，本着学习的心态和大家分享，欢迎大家提供意见或建议

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

2022-09-29 08:41:07 +08:00

回复了 shuanglinzui 创建的主题 › Kotlin › 哪些公司后端用 kotlin 写的

@shuanglinzui 暂时不招，经济不好

2022-09-27 17:17:00 +08:00

回复了 shuanglinzui 创建的主题 › Kotlin › 哪些公司后端用 kotlin 写的

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

2022-09-23 08:47:17 +08:00

回复了 impl 创建的主题 › DevOps › 作为 DevOps 工程师，你知道什么是 git workflow？

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

2022-09-21 17:10:54 +08:00

回复了 tsingke 创建的主题 › 程序员 › 单元测试有落地效果好的团队吗？

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

2022-09-21 17:04:56 +08:00

回复了 tsingke 创建的主题 › 程序员 › 单元测试有落地效果好的团队吗？

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

2022-09-21 17:01:32 +08:00

回复了 tsingke 创建的主题 › 程序员 › 单元测试有落地效果好的团队吗？

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

2022-08-11 09:05:17 +08:00

回复了 dxatgp02 创建的主题 › Java › Java 对象里为什么要用 get set?

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

2022-08-10 17:23:57 +08:00

回复了 BrightLiao 创建的主题 › 程序员 › 我理解的 Smart Domain 与 DDD

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

2022-08-10 14:47:50 +08:00

回复了 BrightLiao 创建的主题 › 程序员 › 我理解的 Smart Domain 与 DDD

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

2022-08-10 09:28:00 +08:00

回复了 BrightLiao 创建的主题 › 程序员 › 我理解的 Smart Domain 与 DDD

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

2022-08-09 16:57:15 +08:00

回复了 BrightLiao 创建的主题 › 程序员 › 我理解的 Smart Domain 与 DDD

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

2022-08-09 10:00:12 +08:00

回复了 BrightLiao 创建的主题 › 程序员 › 我理解的 Smart Domain 与 DDD

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

2022-06-14 13:44:28 +08:00

回复了 TomatoStar 创建的主题 › Java › 僧多粥少环境下，那些小厂 CRUD 30 岁的人未来该何去何从？

不会可以学。。

2022-06-06 09:57:12 +08:00

回复了 auh 创建的主题 › 问与答 › 以集体为导向的价值和以个人为导向的价值观，如何选择？

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

2022-04-19 08:58:16 +08:00

回复了 lotusp 创建的主题 › 程序员 › 分层架构，经典却很难做好

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

1 2 3 4 5 6 7

❮

❯