第三章主要介绍了模型和实现绑定的重要性以及实践方法。
模型驱动设计
模型驱动设计强调的是分析模型和程序设计不分离的一种建模方法。
为什么需要模型驱动设计
这个问题可以拆分成 2 个子问题，第一是我们为什么需要对领域进行建模；第二是为什么建模要和程序设计绑定起来？
关于第一个问题，从前面的章节我们可以知道：如果仅仅编写代码来完成功能却没有建立领域模型，这样制造出来的软件很可能不是领域专家所要的，甚至是不合格的产品。
第二个问题，如果项目设计确实有领域模型，但是软件编码没有和模型对应起来。那么随着项目的开展，模型和项目会逐步脱节，甚至会误导，导致模型形同虚设。
在工作中，很多团队采用的软件开发模式是：产品经理定义需求，项目负责人负责建模，然后将需求再翻译传递给开发人员。这种模式本质上是：分析模型和程序设计分离。项目负责人往往只考虑了模型分析，但没有关注程序设计。开发人员关注程序设计却不理解模型。这背后其实分别对应 2 个模型，领域模型和程序模型，存在一个转换过程。
带来的后果就是编程人员对领域模型理解不到位，导致实现与模型偏差较远；同样的，领域模型很可能无法满足程序设计的需求，甚至无法落地，同时领域模型设计往往不是一蹴而就，前期可能会有很多细节未考虑，导致建模错误，但分析模型和程序设计脱离，会导致程序设计发现的问题，被开发人员自己「错误消化」，无法反馈到项目负责人那，从而措施调整模型的机会。
所以作者主张的方式是：分析模型和程序设计并不作分离，而是寻求一种能够满足这 2 方面需求的单一模型。
模型驱动设计是什么
模型驱动设计，强调单一模型来同时满足分析模型和程序设计的需要。主张：
- 软件系统的各个部分必须忠实地反映领域模型，；
- 模型需要反复检查和修改，反过来使软件可以更自然地实现模型；
- 模型能够支持健壮的通用语言。
如何做
让程序代码成为模型的表达
从模型中提炼术语，让代码自然地表达模型。特别注意：代码的改动很可能意味着模型也被改动，而这个影响很可能影响后续的项目活动。
模型的实现需要依赖编程范式和工具
比如通过面向对象这个武器来帮助建模。
举例：
在现实工作中，常见的需求单都会描述业务逻辑，然而这当中并不是所有的概念都会显式指明。如果没有把隐藏的概念显式化，而是直接编码，很容易变成过程式设计，即通过一系列流程步骤来完成需求，却没有在代码中体现领域模型。如果把这些隐藏的概念显式化，利用面向对象编程范式的武器，则可以阐述模型，使模型具有生命力，也能很好的诠释业务。
HANDS-ON MODELER
实践过程，领域专家、开发人员、技术负责人可能有不同的侧重点，但无论如何，模型驱动设计的重点在于建模和实现不能分离。所以开发人员需要对模型负责；同样参与建模的技术人员也要关注代码，否则对程序实现的约束就没有切身的感受，导致模型变得不再实用，也无法让后期实现过程中产生的细节问题得到有效反馈，阻断模型的调整。
模型与用户的关系
好的模型会引导用户去使用产品，坏的模型则会误导用户。
网友评论