领域驱动设计（Domain Driven Design)
经历过公司一套混乱的技术体系以后，今年初开始重构系统，现记录这一路的感受和体验并总结经验。
历程:公司拥有三套主业务系统，采用了六套技术体系(服务器端四套，前端两套)，涉及多个语言，每次要修改维护的时候都是对体力、时间、精力非常大的消耗，而且最终效果也不尽人意，总结下来问题主要出现在语言不统一(当然不止程序语言，还有交流时对某个概念，名词和认知的统一),需求不明确主流程变更太频繁(架构体系太多太复杂对明确的需求依赖度非常大)
为了破局第一是将技术复杂度和业务复杂度独立开，第二通一语言，因为大家都使用统一的一套通用语言，所以沟通成本会大大减小，不会在讨论A的时候以为是B，第三抓好需求评审关口，第四开发过程中面向领域，面向领域去开发产品有助于我们深入分析产品的内在逻辑，专注于解决当前产品的核心问题，而不是冗余的做很多功能模块，或者现场操作人员反馈的问题就去更改产品逻辑，完了上线后用户不用，你还在那边骂现场人员朝三暮四，乱提需求。
正文：
业务开发大致分为一下几个阶段 需求评审-->技术评审-->测试评审-->开发-->上线后迭代
需求评审
系统设计难以扩展的很大原因就在于需求的不完整。设想一个很大的需求场景，你拿到的只是部分，你设计出来的系统能够满足后来的扩展么？
DDD 强调的有：
需求不要仅仅局限于需求文档，要多多联想生活，个人工作经验，多想想竞品的实现。
不确定的细节多讨论，对象不一定是产品经理，重点是对业务的广度和深度理解比较强的人。
这两点非常重要，做出产品后结果可能是你得到了 10 个场景，但需求文章只做其中的 2 个场景，但剩下的 8 个场景没有浪费，可以为你的系统设计做好扩展，因为你清楚，以后这里可能会改。
至于如何扩展，核心在于抽象，你可以把共用的事情抽象，可以把行为抽象，可以把流程抽象等。
需求评审主要目的是为了弄懂业务和需求，当然弄懂业务和需求是什么很难，有可能你专注于这个业务几年后，才能真正知道该如何定义这个业务，所以我们该把这个目标缩小一下。
于是一般的评审会，很多时候就去听听流程，听听我们要做成什么样子。
DDD 更加强调业务的本质，最后达到能用一两句话直白地把业务描述出来的效果
需求评审的产出最后结果就是需求文档
当然需求文档出来后最好是有一篇最初版的通用语言出来（一定上下文内，对业务概念的一致通用表达，是理清业务是什么，能干什么，以及和其他业务边界的过程）当然这个是理想状态因为产品经理大多不会愿意做这种事情，所以需要开发人员自己整理（时间如果不够也最好能有一个简要版本）,
技术评审
技术评审应该产生三个结果：通用语言，领域模型，数据模型
通用语言已经提了，现在是领域模型
领域模型是领域驱动设计中最重要的最复杂的地方也是最耗时间的地方,当然最好是在需求评审的时候就开始准备
领域模型用来定义领域元素，和管理领域元素的上下文的。
常见的领域元素有：实体、值对象、聚合、领域服务、应用服务、领域能力等。
领域元素之间的上下文指：元素间包含关系和逻辑关系。
数据模型
数据模型，就是在领域模型的基础上进行建表，我们需要表达出一种存储结构
当通用语言、领域模型、数据模型都准备好了之后，当然我们这里准备的只是初版，我们在技术评审会上，需要把团队成员都叫上，由开发主导，向各个成员展示我们的初版成果，大家可以一起讨论，有争议的地方，讨论出结果后，再修改掉。
测试评审
测试评审会的主导者是测试工程师，开发和产品需要注意的有：
测试工程师的表达是否符合通用语言，不符合请纠正。
测试工程师的理解是否和你理解一致，不一致请讨论。
以上阶段完成，DDD 战略设计也基本完成了。
其实和普通的设计流程差别一致的，但思想侧重点不一样，DDD 更加侧重于如何想清楚业务是什么、能干什么、边界在那里，战略设计的所有产出都是围绕着这三个问题展开的。
准备睡觉后面准备开始些战术设计
