老肖想当外语大佬

如果“复杂度”是一个有刻度的尺子，那么我认为，**复杂度越高，软件成本越高**。而我的软件设计决策的所有依据，都构建在这个起点。如果我们期望**降低软件成本**，那么就意味着，我们需要**降低软件的复

在我们实践DDD的过程中，我们意识到，在“代码编写”环节，我们可以非常灵活地调配人力资源，哪怕是被临时调入项目的开发人员，也可以高效地按照设计完成代码的编写，这其中的损耗几乎可以忽略不记。

有创建xxx的需求，即存在一个领域，只是说我们经过思考，某些领域合并进去是比较确定复杂度是可以掌控的，那么我们才做出了合并领域的决定。所以，与其说这是如何划分领域，不如说，这是思考什么时候合并领域

在软件开发过程中，“复用接口（webapi）”、“复用服务（service）”是非常常见的现象，今天我们就来深度探讨一下“复用”和DDD之间的关系，打开一个不同的视角。

如果你期望尽快地走进DDD的世界，那么在分析需求和设计模型时，一定要尽可能先忘记关系数据库和三范式的存在，哪怕你要应用三范式，也应该仅仅将它应用在你的模型的内部，千万不要用它来表达“聚合”之间的关系，

背景 整个《老肖的领域驱动设计之路》系列关于认知的核心部分已经基本闭环，接下来，我将通过一个实战项目来带着大家一起体验从需求到设计，再到实现的过程。

如果你的软件设计思维，没有围绕着“明确和维护边界”来开展，那么大概率是错误的价值判断思路，系统的复杂度大概率也很难被掌控，而具象化出来的现象，就是我们常说的“迭代不动了”。

一千个人眼中有一千个哈姆雷特。在软件工程领域，也有著名的关于如何做好软件设计的观点：“凭经验”。今天通过几分钟的篇幅，呈现我的理解，尝试破除凭经验的魔咒。

本文书接上回《DDD是软件工程的第一性原理？》，关注公众号（老肖想当外语大佬）获取信息： 最新文章更新； DDD框架源码（.NET、Java双平台）； 加群畅聊，建模分析、技术实现交流； 视频和直播在