一 领域驱动设计-运用领域模型-消化知识

目录

• 运用领域模型-消化知识
  • 有效建模的要素
  • 知识消化
  • 持续学习
  • 知识丰富的设计
    • 示例
  • 深层模型

运用领域模型-消化知识

非原创，感谢《领域驱动设计》这本书

有效建模的要素

(1) 模型和实现的绑定。最初的原型虽然简陋，但它在模型与实现之间创建了早期连接，并且在全部后续的迭代中咱们一直在维护该连接。

(2) 创建了一种基于模型的语言。随着项目的进展，双方都可以直接使用模型中的术语，并将它们组织为符合模型结构的语句，并且无需翻译便可理解互相要表达的意思。

我的理解：定义专业词语的字典解释，保证每一个人对每一个术语的理解都是同样的

(3) 开发一个蕴含丰富知识的模型。对象具备行为和强制性规则。模型并不只仅是一种数据模式，它仍是解决复杂问题不可或缺的部分。模型包含各类类型的知识。

(4) 提炼模型。在模型日趋完整的过程当中，重要的概念不断被添加到模型中，但一样重要的是，再也不使用的或不重要的概念则从模型中被移除。当一个不须要的概念与一个须要的概念有关联时，则把重要的概念提取到一个新模型中，其余那些不要的概念就能够丢弃了。

(5) 头脑风暴和实验。语言和草图，再加上头脑风暴活动，将咱们的讨论变成“模型实验室”，在这些讨论中能够演示、尝试和判断上百种变化。当团队走查场景时，口头表达自己就能够做为所提议的模型的可行性测试，由于人们听到口头表达后，就能当即分辨出它是表达得清楚、简捷，仍是表达得很笨拙。

正是头脑风暴和大量实验的创造力才使咱们找到了一个富含知识的模型并对它进行提炼，在这个过程当中，基于模型的语言提供了很大帮助，并且贯穿整个实现过程当中的反馈闭环也对模型起到了“训练”做用。这种知识消化将团队的知识转化为有价值的模型。

知识消化

金融分析师要消化理解的内容是数字。他们筛选大量的详细数字，对其进行组合和重组以便寻求潜在的意义，查找能够产生重要影响的简单表示方式——一种可用做金融决策基础的理解。

高效的领域建模人员是知识的消化者。他们在大量信息中探寻有用的部分。他们不断尝试各类信息组织方式，努力寻找对大量信息有意义的简单视图。不少模型在尝试后被放弃或改造。只有找到一组适用于全部细节的抽象概念后，工做才算成功。这一精华严谨地表示了所发现的最为相关的知识。

知识消化并不是一项孤立的活动，它通常是在开发人员的领导下，由开发人员与领域专家组成的团队来共同协做。他们共同收集信息，并经过消化而将它组织为有用的形式。信息的原始资料来自领域专家头脑中的知识、现有系统的用户，以及技术团队之前在相关遗留系统或同领域的其余项目中积累的经验。信息的形式也多种多样，有多是为项目编写的文档，有多是业务中使用的文件，也有可能来自大量的讨论。早期版本或原型将经验反馈给团队，而后团队对一些解释作出修改。

在传统的瀑布方法中，业务专家与分析员进行讨论，分析员消化理解这些知识后，对其进行抽象并将结果传递给程序员，再由程序员编写软件代码。因为这种方法彻底没有反馈，所以老是失败。分析员全权负责建立模型，但他们建立的模型只是基于业务专家的意见。他们既没有向程序员学习的机会，也得不到早期软件版本的经验。知识只是朝一个方向流动，并且不会累积。

我的理解：如今依然有公司在这样作,业务需求人员定义需求，再由架构师或者组长进行翻译，以后直接分配给程序员任务，最后作出的程序每每和需求误差较远，大部分会议是组行和业务参加，真正实现功能的程序员没有参与到会议讨论中来。

有些项目使用了迭代过程，但因为没有对知识进行抽象而没法创建起知识体系。开发人员听专家们描述某项所需的特性，而后开始构建它。他们将结果展现给专家，并询问接下来作什么。若是程序员愿意进行重构，则可以保持软件足够整洁，以便继续扩展它；但若是程序员对领域不感兴趣，则他们只会了解程序应该执行的功能，而不去了解它背后的原理。虽然这样也能开发出可用的软件，但项目永远也不会从原有特性中天然地扩展出强大的新特性。

好的程序员会天然而然地抽象并开发出一个能够完成更多工做的模型。但若是在建模时只是技术人员唱独角戏，而没有领域专家的协做，那么获得的概念将是很幼稚的。使用这些肤浅知识开发出来的软件只能作基本工做，而没法充分反映出领域专家的思考方式。

在团队全部成员一块儿消化理解模型的过程当中，他们之间的交互也会发生变化。领域模型的不断精化迫使开发人员学习重要的业务原理，而不是机械地进行功能开发。领域专家被迫提炼本身已知道的重要知识的过程每每也是完善其自身理解的过程，并且他们会渐渐理解软件项目所必需的概念严谨性。

有这些因素都促使团队成员成为更合格的知识消化者。他们对知识去粗取精。他们将模型重塑为更有用的形式。因为分析员和程序员将本身的知识输入到了模型中，所以模型的组织更严密，抽象也更为整洁，从而为实现提供了更大支持。同时，因为领域专家也将他们的知识输入到了模型中，所以模型反映了业务的深层次知识，并且真正的业务原则得以抽象。

模型在不断改进的同时，也成为组织项目信息流的工具。模型聚焦于需求分析。它与编程和设计紧密交互。它经过良性循环加深团队成员对领域的理解，使他们更透彻地理解模型，并对其进一步精化。模型永远都不会是完美的，由于它是一个不断演化完善的过程。模型对理解领域必须是切实可用的。它们必须很是精确，以便使应用程序易于实现和理解。

我的理解：对于业务和开发来讲，最大的问题是思惟想法的同步，同步最大的问题是交流沟通，程序员大部分相对内向沉默，业务有时候也会厌烦重复的表述，形成理解误差。创建模型并共同改进精化能够很好的解决这个问题，既然开发人员的思惟方式（机器思惟）和业务人员的思惟方式（功能结果导向思惟）不一样，那么就使用一个中间翻译的语言，这个语言就叫作模型，也是抽象的模型。是你们一块儿来制定的一种抽象表达方式，每一个人都要参与其中，而且不断进行更新。模型也充当了业务转化为开发逻辑的一种中间过程表示。

持续学习

当开始编写软件时，其实咱们所知甚少。项目知识零散地分散在不少人和文档中，其中夹杂着其余一些无关信息，所以咱们甚至不知道哪些知识是真正须要的知识。看起来没什么技术难度的领域极可能是一种错觉——咱们并没意识到不知道的东西究竟有多少。这种无知每每会致使咱们作出错误的假设。

同时，全部项目都会丢失知识。已经学到了一些知识的人可能干别的事去了。团队可能因为重组而被拆散，这致使知识又从新分散开。被外包出去的关键子系统可能只交回了代码，而不会将知识传递回来。并且当使用典型的设计方法时，代码和文档不会以一种有用的形式表示出这些来之不易的知识，所以一旦因为某种缘由人们没有口头传递知识，那么知识就丢失了。

我的理解：团队的解散，人员的离职或变动，文档的丢失和散乱，都会使项目组丢失知识，有时候代码写完了可是没有文档或者注释（程序员黑话：先开发产品功能，后写文档，其实就是懒得写），别人接手须要经历很是大的痛苦，而后疯狂吐槽之前的开发人员。这些均可以归于知识的丢失。

高效率的团队须要有意识地积累知识，并持续学习。对于开发人员来讲，这意味着既要完善技术知识，也要培养通常的领域建模技巧。但这也包括认真学习他们正在从事的特定领域的知识。那些善于自学的团队成员会成为团队的中坚力量，涉及最关键领域的开发任务要靠他们来攻克，这个核心团队头脑中积累的知识使他们成为更高效的知识消化者。

关键的模型元素被保留下来，早期工做启动了知识消化的过程，这使得全部后续工做更加高效：团队成员、开发人员和领域专家等都学到了知识，他们开始使用一种公共的语言，并且造成了贯穿整个实现过程的反馈闭环。

我的理解：全部人都参与，制定模型，学习知识（业务逻辑或者开发思惟或者处理流程等等都是知识），后期团队效率会很是高，就算人员变动，只须要理解开发过程当中一块儿制定的模型就能够了。

知识丰富的设计

当咱们的建模再也不局限于寻找实体和值对象时，咱们才能充分吸收知识，由于业务规则之间可能会存在不一致。领域专家在反复研究全部规则、解决规则之间的矛盾以及以常识来弥补规则的不足等一系列工做中，每每不会意识到他们的思考过程有多么复杂。软件是没法完成这一工做的。正是经过与软件专家紧密协做来消化知识的过程才使得规则得以澄清和充实，并消除规则之间的矛盾以及删除一些无用规则。

我的理解：业务或者产品若是不懂开发，会提出一些天马行空的功能，不会意识到他们的想法实现起来由多复杂。好比：产品经理要程序要开发一个功能，要求app根据手机壳的颜色而改变主题颜色（新闻有报道，产品经理被打了，哈哈哈）。你们一块儿紧密协做来消化知识，能够消除这些矛盾或者无用的想法。

示例

咱们从一个很是简单的领域模型开始学习，基于此模型的应用程序用来预订一艘船在一次航程中要运载的货物

们规定这个应用程序的任务是将每件货物（Cargo）与一次航程（Voyage）关联起来，记录并跟踪这种关系。如今看来一切都还算简单。应用程序代码中可能会有一个像下面这样的方法

因为总会有人在最后一刻取消订单，所以航运业的通常作法是接受比其运载能力多一些的货物。这称为“超订”。有时使用一个简单的容量百分比来表示，如预订110%的载货量。有时则采用复杂的规则——主要客户或特定种类的货物优先。这是航运领域的一个基本策略，从事航运业的业务人员都知道它，但在软件团队中可能不是全部技术人员都知道这条规则。需求文档中包含下面这句话：容许10%的超订。（这个时候由问题了哈）

如今，一条重要的业务规则被隐藏在上面这段方法代码内，很是容易误解，咱们主要考虑如何把这条规则更清楚地表达出来，并让项目中的每一个人都能了解到它。这将使咱们获得一个相似的解决方案。

(1) 若是业务规则如上述代码所写，不可能有业务专家会经过阅读这段代码来检验规则，即便在开发人员的帮助下也没法完成。

(2) 非业务的技术人员很难将需求文本与代码联系起来。若是规则更复杂，状况将更糟。

修改为下面这样：

如今全部人都清楚超订是一个独特的策略，并且超订规则的实现即明确又独立。

如今，我并不建议将这样的精细设计应用到领域的每一个细节中。第15章将深刻阐述如何关注重点以及如何隔离其余问题或使这些问题最小化。这个例子的目的是说明领域模型和相应的设计可用来保护和共享知识。更明确的设计具备如下优势：

(1) 为了实现更明确的设计，程序员和其余各位相关人员都必须理解超订的本质，明白它是一个明确且重要的业务规则，而不仅是一个不起眼的计算。

(2) 程序员能够向业务专家展现技术工件，甚至是代码，但应该是领域专家（在程序员指导下）能够理解的，以便造成反馈闭环。

我的理解：模型要把重要的细节表达出来，不能隐藏的本身知道的认知中（就不告诉别人，说你这样作就好了，这样很差），要体现出为何是这样的，是什么致使必需要加入这个，要让模型在成为沟通的桥梁时更加明确易懂。

深层模型

有用的模型不多停留在表面。随着对领域和应用程序需求的理解逐步加深，咱们每每会丢弃那些最初看起来很重要的表面元素，或者切换它们的角度。这时，一些开始时不可能发现的巧妙抽象就会渐渐浮出水面，而它们偏偏切中问题的要害。

前面的例子大致上是基于一个集装箱航运项目，这是本书列举的几个项目之一，本书还有几个示例会引用这个项目。本书所举的示例都很简单，即便不是航运专家也能理解它们。但在一个须要团队成员持续学习的真实项目中，要想创建实用且清晰的模型则要求团队成员既精通领域知识，也要精通建模技术。

在这个项目中，因为航运从预定货运开始，所以咱们开发了一个可以描述货物和运货航线等事物的模型。这是必要且有用的，但领域专家却不买帐。他们有本身的考虑业务的方式，这种方式是咱们没有考虑到的。

最后，在通过几个月的知识消化后，咱们知道货物的处理主要是由转包商或公司中的操做人员完成的，这包括实际的装货、卸货和运货。航运专家的观点是，各部分之间存在一系列的责任传递。法律责任和执行责任的传递由一个过程控制—从托运人传递到某个本地运输商，再从这家运输商传递到另外一家运输商，最后到达收货人。一般，在一些重要的步骤中，货物停放在仓库里。在其余时间里，货物则是经过复杂的物理步骤来运输，而这些与航运公司的业务决策无关。在处理航线的物流以前，必须先肯定诸如提单等法律文件以及支付流程。

对航运业务有了更深入的认识后，咱们并无删除Itinerary（航线）对象，但模型发生了巨大改变。咱们对航运业务的认识从“集装箱在各个地点之间的运输”转变为“运货责任在各个实体之间的传递”。处理这些责任传递的特性再也不是一些附属于装货做业的次要特性，而是由一个独立的模型来提供支持，这个模型正是在理解了做业与责任之间的重要关系以后开发出来的。

知识消化是一种探索，它永无止境。

我的理解：随着对业务的理解更加深入之后，模型同时也要进行更新，会变得复杂，怎么办？开发容易理解的一种形式是：就至关于sql中作子查询，java开发中就小模块封装，大模块调用函数。模型也是同样，再作一个新模型，对某一部分功能作抽象，由大模型连接过去。例如：a-b-c原来是一个模型，后来增长到a-b-c-c1-c2-c3，c的功能原来越多，这个时候能够作成这样：模型1是a-b-C,模型C（独立小模型）：c1-c2-c3。这就是深层模型的理解。