DDD原著 -- 第三章绑定模型和实现

发布时间：2020-12-14 02:12:17 所属栏目：百科来源：网络整理

导读：领域驱动设计要求模型不仅能够指导早期的分析工作，还应该成为设计的基

领域驱动设计要求模型不仅能够指导早期的分析工作，还应该成为设计的基础。
严格按照基础模型来编写代码，能够使代码更好地表达设计含义，并且是模型更符合设计。
缺乏设计基础概念的软件充其量也只是一种机械化的产品，只实现有用的功能却无法解释操作的原因。
很多设计方法都提倡使用完全脱离于程序设计的分析模型，且通常这二者是由不同的人员开发的。但DDD不提倡，因为这样会有很多问题。
如果整个程序设计或者其核心部分没有与领域模型相对应，那么这个模型就是没有价值的，软件的正确性也值得怀疑。模型和设计功能之间太过复杂的对应关系也是难于理解的，在实际项目中改变设计时也无法维护这种关系。分析和设计工作全无关联，导致在这另个过程中所获得的知识无法彼此共享。
分析工作一定要抓住领域内的基础概念，并且用易于理解和易于表达的方式描述出来。
Model-Driven Design（模型驱动设计）不再将分析模型和程序设计分离开，而是寻找一种能够满足这两方面需求的单一模型。
绑定模型和程序设计是切实可行的。不能因为技术问题考虑而削弱分析功能，也不能只反映领域概念却舍弃了软件设计原则。模型和设计的绑定需要的是在分析和程序设计阶段都能发挥作用的模型。这样就结合为一个统一的迭代开发过程。
软件系统的各个部分的设计应该忠实的反映领域模型，以便体现出这二者之间的明确对应关系。我们应该反复检查并修改模型，在软件中更加自然地实现模型，即使想让它反映出更深层次的领域概念也应如此。我们需要的模型不但应该满足这两种需求，还应该能够支持健壮的Ubiquitous Language。
从模型中获取用于程序设计和基本任务分配的术语。程序代码就是模型的表达。修改代码可能就是修改模型。完全依赖模型的实现通常需要支持建模范式的软件开发工具和语言，比如：面向对象的编程。
知识消化人员需要研究模型的各个选项，并将它们细化为实用的软件元素。软件开发于是就成了一个不断精化模型、设计和代码的统一的迭代过程。
要保证模型和设计之间的严格的一致性，必须要运用由软件工具支持的建模范式，它可以直接模拟模型中的概念。如：面向对象编程语言，C#、Java、Prolog。。。对象设计的真正突破是用代码来描述模型中的概念。
在Model-Driven Design中，建模范式是一种逻辑，而模型则是一组逻辑规则以及这些规则所依据的事实。
Hands-ON Modeler（建模人员参与程序开发）
如果编写代码的人员认为自己没必要对模型负责，或者不知道如何让模型为应用程序服务，那么这个模型就和程序没有任何关联。如果开发人员没有意识到改变代码就意味着改变模型，那么他们对程序的重构不但不会增强模型的作用，反而会消弱他的效果。同样，如果建模人员不参与到程序实现的过程中，那么对程序实现的约束就没有切身的感受，即使有也会很快忘记。最终模型将变得不再实用。最后一点，如果项目组的分工阻断了设计人员与开发人员的协作，使他们无法领悟Model-Driven Design 的奥妙，那么经验丰富的设计人员则不能将自己的知识和技术传递给开发人员。
任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。任何负责修改代码的人员则必须学会用代码来表达模型。每一个开发人员都必须不同程度地参与模型讨论并且与领域专家保持联系。参与不同工作的人都必须有意识地通过Ubiquitous Language与接触代码的人及时交换关于模型的想法。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

DDD原著 -- 第三章 绑定模型和实现

DDD原著 -- 第三章绑定模型和实现