《领域驱动设计》第三章 绑定模型和实现

3.1 模式：MODEL-DRIVEN DESIGN

领域设计之中的真实问题

• 代码编写没有与模型紧密相连
• 模型和程序设计之间的联系存在破坏
• 分析模型是理解工具无法与程序实现紧密相连
• 纯粹的分析无法很好的解决程序中的细节问题

什么是模型驱动设计

        不在将分析模型和程序设计分离开，寻求一种能够满足两方面的单一模型。程序设计中的每个对象都反映了模型中相应概念。

如何做？

支持建模范式的工具和语言——面向对象编程

 模型驱动设计的两个基本要素

• 模型要支持有效的实现
• 模型可以抽取出关键的领域知识

3.2建模范式和工具支持

        为了使MODEL-DRIVEN DESIGN 发挥作用，一定要在可控范围内严格保证模型与设计之间的一致性。要实现这种严格的一致性，必须要运用由软件工具支持的建模范式，它可以在程序中直接创建模型中的对应概念。

• Prolog语言

建模范式是逻辑，模型则是一组逻辑规则以及规则对应的事实。

• Fortran

数学模型

• 面向对象编程

3.3揭示主旨：为什么模型对用户至关重要

        从理论上讲，也许你可以向用户展示任何一种系统视图，而不管底层如何实现。但实际上，系统上下层结构的不匹配轻则导致误解，重则产生bug。让我们来看一个简单的例子——微软IE浏览器的早期版本中，网站书签功能对应的模型是如何误导用户的。

IE浏览器早期版本中，只是把书签当做是一个包含URL的文件。

但同时出现的问题是：

1. 网页标题含有非法字符，就会提示文件错误
2. 标题已经包含非法字符，程序则会偷偷的把字符删掉

领域问题：

        如果收藏夹实际上只是快捷方式文件的集合，那么应该将这一事实告诉用户，以便让收藏夹的功能更加清晰。

3.4 模式：HANDS-ON MODELER（亲身实践的建模者）

        人们总是把软件开发比喻成制造业。这个比喻的一个推论是：经验丰富的工程师做设计工作，而且技能水平较低的劳动负责组装产品。虽然开发团队中的每个成员都有自己的职责，但是将分析，建模，设计和编程工作过度分离会对MODEL-DRIVEN DESIGN 产生不良影响。

这种思想导致的问题：

• 模型的一些意图在其传递中丢失
• 完全脱离模型设计
• 建模人员不参与无法约束

结论：

将建模过程和编程过程完全分离是行不通的。

        任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。任何负责修改代码的人员必须学会用代码来表达模型。每一个开发人员都必须不同程度的参与模型讨论并且与领域专家保持联系。参与不同工作的人都必须有意识的通过 UBIQUITOUS LANGUAGE 与接触代码的人及时交换关于模型的想法。