认识达内从这里开始

领域驱动设计是大多数软件编程开发程序员在开发软件的时候都需要熟练掌握的一个软件架构设计模式，下面我们就通过案例分析来简单了解一下，领取驱动设计用法分析。

领域驱动设计指出传统的需求分析和模型设计、代码编写是相互割裂的，传统有需求分析师和系统设计师两个独立的职位，这种割裂导致相互之间的不匹配，比如系统设计不能完全反映出需求分析，而代码又和系统设计割裂，各自有一套自己的私有语言，相互之间很难沟通。

DDD强调需求分析、建模和编码的内在统一性，三者(以及执行三者的人)之间使用一致的领域通用语言沟通，因而业务专家、设计师、程序员之间能够很容易达成共识。

现实情况是，程序员和业务专家(以产品经理为代表)之间的沟通要么存在严重的鸿沟，要么使用非业务(往往是技术性的)语言沟通，背离真正的业务领域概念。程序员很喜欢用技术性语言(甚至直接拿数据库说事)和别人(哪怕是非技术人员如客服、销售)沟通，导致各执一词。一般敏捷团队往往只有一个产品经理，而有好几个技术人员，往往会出现以技术性语言主导沟通的场面(如果产品经理本身不注重对团队的业务语言引导的话)。

程序员为何那么喜欢用技术性语言和别人沟通?一方面，程序员的沟通对象常常也是程序员，技术性语言沟通成本低;另一方面，他们往往在沟通的同时就在想着实现方案(或者说沟通本身就是对实现方案的描述)。

然而，技术语言沟通对业务模型的建立有着很严重的损害。技术本身和业务是两个领域的东西，技术语言在现实中的代表就是“数据库语言”，比如“某个时候将某表的某字段标记为1”，这于业务本身无任何意义。这种思维导向会让我们脑海中越过建模而直达存储实现低层。另一方面，这种技术与业务语言的混杂会让业务逻辑本身耦合进存储层的设计中。例如，单从存储设计(技术实现)上来说，“登录状态”应当由单独的字段来标记，而在业务领域中，“登录”与“退出登录”操作会导致另外的状态变化(存储设计上表现为另一个字段)，当我们在进行存储层设计时过多的代入业务逻辑本身(或者毋宁说在业务逻辑描述时过多地代入存储层的技术实现)，我们可能会用另一个字段(存储着其他的状态)来代表登录状态(并且很自豪地认为这样能节约存储空间——的技术主导一切的思维)。这里的问题是：登录状态的存储实现依赖于业务逻辑，由于业务逻辑是不稳定的(相对于存储层)，因而这里作为底层的存储层设计也是不稳定的。(实际上会员的登录状态存储就存在这样的问题)

DDD强调：

从需求分析到代码实现到测试的整个过程各人员之间的沟通需要使用一致的无歧义的领域内通用语言。

该通用语言必须能够准确反映业务需求和领域知识(而不是反映技术实现)。

对于程序员来说，DDD的这种思想可概括为：代码即模型，编码即设计。我们写出来的代码，类与类之间的调用关系，方法、变量的命名都要反映领域通用语言本身。DDD非常强调命名，对于DDD来说，编程本身就是语言活动(不是机器语言)。DDD强调语言的重要性，这语言是人类的语言，而且是某特定领域下的人类语言。

现实情况是，我们的代码中充斥着大量的面向数据库的语言。例如update()、delete()充斥在各种业务代码中。“将字段A的值更新为b”是技术(数据库)语言，不是业务领域语言。更有甚，在控制器层写个UpdateFields()搞定一切更新操作。

然而，并不是所有的技术实现都要以当前业务领域语言来诠释，实际上这也是做不到的。有些技术实现并非属于业务领域之内，例如持久化存储、事件系统、消息队列等，这些不属于当前业务领域的技术实现当然也就不需要遵守该业务领域通用语言(它们需要遵守的是各自的领域语言规约)。这种业务领域边界在DDD中叫“限界上下文”，上下文内的东西属于六边形架构中的内圆部分，而外部的东西属于外圆，内外圆通过契约适配通信(适配器)。

DDD并非泛泛的理论阐述，它有一套详细的实现体系(方法论)，如实体、值对象、聚合、聚合根、领域服务、仓储、各种设计模式等，此处不做详细阐述(那得写成一本厚厚的书，而且DDD本身是很注重实践的，一百个人就有一百种实现方式，重在掌握其核心思想)。

这里提出DDD，重点在于对比我们现在使用的开发/设计模式：面向服务设计以及面向数据库设计。在DDD中，实体是核心，服务只是辅助，而数据库则是领域外的基础设施。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。