结束语｜DDD，是技术也是艺术
权衡的艺术
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
DDD，是技术也是艺术 在这篇文章中，作者钟敬以“DDD，是技术也是艺术”为题，分享了对技术和艺术的思考。他指出，软件开发不仅是技术，更是一门艺术，技术偏重逻辑和套路，而艺术则侧重于经验、洞察和审美。他强调了架构师需要将技术和艺术结合起来，以及软件开发中的“权衡的艺术”、“抽象的艺术”和“抓住本质的艺术”。 在“权衡的艺术”方面，作者提到了架构师需要谦卑地分析和权衡，以做出更好的决策。他介绍了架构决策记录（ADR）的方法，以便进一步优化和演进。在“抽象的艺术”方面，作者强调了抽象能够更准确地理解业务，同时也带来更灵活的软件设计，但抽象程度的选择是一个艺术问题。在“抓住本质的艺术”方面，作者指出DDD解决的是软件开发的本质问题，而人工智能编程目前解决的仍然是软件开发的非本质问题。他鼓励读者学习DDD，因为通过可视化、抽象化、严格化的方法建立领域模型的艺术，仍然无法被人工智能取代。 总的来说，这篇文章通过对技术和艺术的思考，强调了软件开发中的艺术性，并鼓励读者在技术和艺术的交汇处不断探索、学习和成长。
《手把手教你落地 DDD》，新⼈⾸单¥59
全部留言(7)
- 最新
- 精选
扶程星云非常感谢老师的分享，第一次读完，很多地方懵懂，我会不断重复拜读佳作！作者回复: 共同进步！
2023-07-28归属地：江苏1
无问钟老师 golang有什么参考的ddd项目吗作者回复: 我对Go不是很熟，可以参考下面的文章： https://mehdihadeli.github.io/awesome-go-education/ddd/ https://programmingpercy.tech/blog/how-to-domain-driven-design-ddd-golang/ https://www.calhoun.io/moving-towards-domain-driven-design-in-go/
2023-06-21归属地：上海2
Sam Jiang技术也需要洞察力，但是艺术需要想象力。 学这门课让我开了眼界，发现曾经困扰自己的问题，已经有人想出了解决方法。并不是人类一思考，上帝就发笑。感谢钟老师。作者回复: 共同进步！
2023-03-12归属地：上海
quietwater老师能加餐讲讲三元关联吗？ 我说说我的猜测：比如一个用户在一个系统里，可以访问两个不同的企业里的数据，在一个企业里的角色是管理员，在另一个企业里的角色客户。这里的业务逻辑就是三元关联，一个用户在不同的企业下，角色不一样。作者回复: 这个理解是正确的。企业，用户，角色，三者构成了三元关系
2023-03-11归属地：北京
aoe收获很大，看了钟老师在之前文章中提到的「低配版」DDD，对坚持学习起到了很大帮助。在工作中恰好遇到了「项目管理」的问题，正在使用 DDD 开发一个项目，帮助解决问题。这是一个练习项目，等第一版完成后，分享出来和大家一起讨论。 感谢钟老师带我入门 DDD ！作者回复: 你的学习态度和学习方法都很棒，在实践中遇到什么问题可以继续在群里或者留言区探讨。
2023-03-10归属地：浙江2
hacker time实际项目不会只有一个应用，在自己的项目中实践这门课时遇到的问题是有2个应用，一个是微信小程序，一个是后台管理系统，不知道怎么组织代码目录结构了，2个应用都有自己的restful和repository实现类，2个应用的功能有相同的有不同的，领域模型建模时建了一个包含从两个应用来的所有逻辑，但是repository接口只在domain层，导致两个应用的repository实现类里面的方法有的是空方法，而如果为2个应用在domain层建立自己的repository接口，又会导致领域逻辑不包括来自2个应用的所有逻辑，这样领域逻辑就不完整来，导致不知道怎么建模了？是每个应用单独建模吗？可是它们是一个系统里面的2个应用啊，怎么能单独建模呢？作者回复: 这个问题，可能是限界上下文拆分问题，也可能是同一个上下文内的建模技巧问题，还可能是代码实现技巧问题。只能对着具体案例才能聊清楚了。
2023-03-10归属地：湖北
Geek默默潜水学习，感谢作者分享！2023-03-09归属地：北京1
