认识达内从这里开始

随着互联网的不断发展，程序员在学习软件编程开发领域能够掌握的编程知识也越来越多了，而本文我们就通过案例分析来了解一下，领域驱动设计基础知识与注意事项分析。

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

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

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

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

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

DDD强调：

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

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

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

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。