随着微服务和中台的兴起，领域驱动设计被越来越多的提起。
设计与过程密不可分，否则设计就是纸上谈兵。
- 系统的架构设计或者领域模型是动态的，是演化而来并且将继续演化的。不是静态设计出来的。所以要“每个月过一下架构图”。
- 面对一个新系统（新人入职，交接过来一个系统。。。）时，应该先了解他的演化过程，有些东西看起来一坨，可能并没有想象的那么糟糕，他还是切实的在解决业务问题，对一些老旧系统，谨慎的“推到重来”。这时候，系统里的“老人”会显得很重要，因为他们了解演化过程，也有比较深层次的领域知识。
领域驱动设计的实质，就是消化吸收大量知识，最后产生一个反应深层次领域知识并聚焦于关键概念的模型。
这里面有几个关键词。
- 首先是消化知识，这里指的知识说的是领域知识，或者说业务知识。比如“京东所有处罚商家的规定，首先至少要向所有商家公示7天以上才可以被执行，否则会有法律风险。”这就是奖惩领域的知识。
- 然后是关键概念，根据刚刚消化得到的知识，我们会提取几个概念：条例=京东颁布的处罚商家的规定。公示期=条例已经被颁布但还不能被执行的时间区间。然后我们就用这些概念来组成我们的领域模型，也用这些概念来互相交流。
- 最后是模型，那模型是什么呢？
模型是一种简化，它是对现实的解释。
- 首先，现实是有无数面的，我们观察到的永远是现实的某种解释，而不是现实本身。模型就是把与解决问题密切相关的方面抽象出来，而忽略无关的细节的那种解释。比如，我们人类看到树是绿的，火是红的，但狗的眼睛构造与人不同，看不到这些光谱，它们看到的树是偏黄的，火是偏褐色的。那么问题来了，树和火到底是什么颜色？根本就不知道，甚至，颜色这个概念本身，也是一种模型，也是一种对现实的解释。
- 所以，领域模型，不是某种架构图。而是图要传达出来的思想，也可以不用图，用文档表示，甚至可以用代码表示（极限编程XP推崇的就是——代码即文档）。
- 领域模型也不单单是领域专家（业务人员）头脑中的知识，只有大家共同认知到并且认可的知识才是领域模型。所以我们在实际工作中，一项非常难但非常重要的工作就是统一业务，产品，研发。。。所有参与人员对领域模型的认知。我理解，这也正是我们采用和推动领域驱动设计的一个重要原因。
有效建模的要素
那我们如何有效的建立我们的领域模型呢？
- 模型和实现的绑定。就如第一点所说，我们设计的模型，一定要和代码实现绑定，别讨论的时候说的好像很有道理很完美，实现的时候又这里一个特殊逻辑那里一个实现不了。就成了所谓的PPT架构师了。
- 建立了一种基于模型的语言。我觉得这是最重要的要素没有之一。模型是团队所有成员使用的通用语言的中枢。只有当业产研都使用同一套语言来沟通的时候，效率才会高，摩擦才会少。
- 开发一个蕴含丰富知识的模型
- 提炼模型
- 头脑风暴和实验
不同的团队成员使用不同的术语而不自知
很多时候，业务使用业务的语言，产品使用产品的语言，研发使用研发的语言在讨论问题，讨论了半天也没结果，或者讨论出来了一个带有歧义的结果。甚至，同一个词，在不同语言里表达的概念完全不同，比如“中台”比如“组件化”。这个时候需要共事的团队使用同一种公共语言，然而任何一方的语言都不能成为公共语言。需要融合提炼一套公共语言。确保团队在内部是的所有交流，以及代码中坚持使用这种语言。在画图，写文档，写代码，特别是讲话时也要使用这种语言。
