领域建模：方法与实例

本书关注对软件的成败生死攸关而在实际开发过程中往往被严重忽视的部分：业务分析和领域建模，以及领域建模的产物领域模型，并给出几个领域建模的实例。

对软件开发来说（对其他行业也一样），成功的标准有两条：

• 做正确的事（Do the RIGHT thing）;
• 正确地做事（Do the thing RIGHT）。

如果客户需要你画一只老虎，但是你给他画了一条狗，即使你把狗画得栩栩如生（Do the thing RIGHT），却不是客户需要的（Do the WRONG thing），那么这幅画就是彻底失败了。

与其他行业相比，软件开发有一个特殊性：我们是为其他行业提供自动化解决方案。我们不但要掌握编程语言、类库、框架、工具、操作系统、数据库等等软件技术，以便“Do the thing RIGHT”，更需要能够快速领会和深刻洞察业务领域的概念、规则和逻辑，形成一个正确反映业务现实本质的领域模型，代表我们对业务领域的认识、理解和洞察，在业务专家、客户、用户、开发人员、测试人员中间形成共识，这样才能确保我们是在“Do the RIGHT thing”，我们开发的软件才有可能成为既“解决了正确的问题”又“正确地解决了问题”的解决方案。否则必然会刻鹄成鹜，画虎类犬。

业务分析和领域建模致力于“Do the RIGHT thing”，而设计和实现致力于“Do the thing RIGHT”。前者远比后者重要。如果方向错误，那么，你跑的越快，只会离目标越远。跑得快只有在方向正确的时候才有用。如果对业务需求和本质的理解错误，是无法通过高超的技术手段来弥补的。

但是国内大多数的软件公司、团队和开发者，在业务分析和领域建模方面做得不够好，究其原因，大概是因为：

• 认识错误。以为软件开发就是数据建模，是以数据库为中心的增删改查，完全没想到需要领域建模。这样的开发模式往往是从现有数据库或报表入手，实现客户的表层需求，遗漏业务的本质机制。
• 对业务分析和领域建模的重要性认识不足，把大部分资源和精力投放在编码实现上。
• 缺乏领域建模方面的指导和训练，无法快速而深刻地洞察业务领域的本质，因此形成的领域模型充满各种误解和缺陷。
• 开发人员偏爱钻研具体软件技术，不敢或不愿踏足业务领域分析。

如果建模不足（不够准确，不够深刻，不够抽象），会产生下面的后果：

• 你的软件不符合或不完全符合客户的需要。
• 你的软件只符合客户的浅层需要和当前需要，当客户需要有变化时（必然如此！），难以扩展和变更，或者需要对大面积的代码做伤筋动骨的改动。
• 你的软件只符合当前客户的需要，当移植给同行业的其他客户使用时，需要对你的代码做伤筋动骨的改动。
• 你的概念模型和技术实现紧密耦合，当技术升级或更换技术实现时，需要对你的代码做伤筋动骨的改动。

好的领域模型深刻反映了业务领域的本质，它不仅满足客户的表面需要，还能满足客户的深层需要；它不仅满足客户的当前需要，还能满足客户的未来需要；它不仅满足单一客户的需要，还能满足相同领域其他客户的需要。它使得软件可以快速、安全、低成本地进行扩展和修改，而不影响系统的主体结构。好的领域模型独立于软件技术实现，在软件技术快速升级换代的同时恒久地发挥作用。

谁需要掌握领域建模的知识？

领域模型要在领域专家、客户、开发人员和测试人员之间形成没有歧义的共识。理想情况下，应该以领域专家（即那些在现实业务领域中的资深从业者）为主进行建模，软件开发团队（尤其是其中的业务分析师）辅助。有时候，领域专家只能提出表层模型，我们需要引导和激发他们挖掘领域的深层本质，获得真正反映业务领域本质的深层模型。领域模型是所有利益相关者的通用语言。每个开发人员都应该掌握领域建模技巧并参与建模过程。

目前市面上关于编程语言、类库框架以及其他种种软件技术的书籍和培训汗牛充栋，但关于领域建模和领域模型的书籍和培训却几乎为零。据我所知，关于这个主题的相关书籍，只有Martin Fowler的《分析模型》，Peter Coad的《对象模型：策略、模式与应用》和Len Silverston的《数据模型资源手册》三卷本等寥寥数本。而且后者论述的还只是数据模型而不是领域模型。这些书籍都是直接给出领域建模的最终产物：各个具体领域的领域模型（Domain Model）。这相当于直接把鱼（Fish）送给你，而不是教导你渔（Fishing）的方法。本教程的目标是“授人以渔”而不是“授人以鱼”，着重点在探讨领域建模（Domain Modeling）的技艺，而不是提供现成的领域模型（Domain Model）。所以几个范例建模项目，都是一步步对模型进行演化，而不是直接呈现终极模型。