SOA、ESB、中台、微服务、分布式架构等一系列名词，都无法解决业务需求不断变化的及时响应，领域驱动设计的概念又重新流行了起来。没有领域模型，只是靠代码编写完成一个又一个功能，复杂的领域需求会使得他们无法交流讨论，使工作陷入泥沼。有少许领域模型，但是没有维护好模型与代码直接的联系，两者产生差异，无法实现。

分析设计发展的三个阶段：

第一阶段：围绕数据库的驱动设计，新项目总是从设计数据库及其字段开始。

第二阶段：面向对象的分析设计方法诞生后，有了专门的分析和设计阶段之分，分析阶段和设计阶段是断裂的。

第三阶段：融合了分析阶段和设计阶段的领域驱动设计。

    领域驱动设计(DDD，Domain-Driven Design)，软件开发不是一蹴而就的事情，我们不可能在不了解产品(或行业领域)的前提下进行软件开发，在开发前，通常需要进行大量的业务知识梳理，然后才到软件设计的层面，最后才是开发。而在业务知识梳理的过程中，我们必然会形成某个领域知识，根据领域知识来一步步驱动软件设计，就是领域驱动设计的基本概念。

    项目领域知识零散地分散在很多人和文档中，其中夹杂着其他一些无关信息，因此我们甚至不知道哪些知识是直接需要的知识。看起来没什么技术难度的领域很可能是一种错觉--我们并没有意识到不知道的东西究竟有多少。这种无知往往会导致我们做出错误的假设。

    同时，所有项目都会丢失知识。已经学到了一些知识的人可能干别的事去了。团队可能由于重组而被拆散，这导致知识又重新分散开。被外包出去的关键子系统可能只交回了代码，而不会将知识传递回来。而且当使用传统的设计方法时，代码和文档不会以一种有用的形式表示出这些来之不易的知识，因此一但由于某种原因人们没有口头传递知识，那么知识就丢失了。

    高效率的团队需要有意识地积累知识，并持续学习。对于开发人员来说，这意味着即要完善技术知识，也要培养一般的领域建模技巧。但这也包括认真学习他们正在从事的特定领域的知识。

    那些善于自学的团队成员会成为团队的中坚力量，涉及最关键领域的开发任务要靠他们来攻克。这个核心团队头脑中积累的知识使他们成为更高效的知识消化者。

    软件开发中，需求是解决“系统怎样好卖”的问题，设计是解决“降低开发成本”的问题。经过多年的积累，软件公司往往会从单一的产品，变成围绕核心领域的一系列产品线，其中的各款产品都存在很多相同的机制，但又有许多不同。目前大多数软件公司的复用往往只局限于基础平台级别的复用，很难做到对本公司所处核心域的组件作复用，如果能够在这方面做一些努力，对降低维护成本，改善利润 会有很大帮助。