135 lines
18 KiB
Markdown
135 lines
18 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
059 四色建模法
|
||
或许正是认识到彩色 UML 在建模过程的不足之处，ThoughtWorks 的徐昊才在彩色 UML 基础之上提出了自己的“四色建模法”。可考的四色建模法资料仅见于徐昊在 InfoQ 上发表的文章运用四色建模法进行领域分析。在这篇文章中，徐昊回答了建模活动的一个关键问题：怎么才能保证建模的正确性？徐昊认为：
|
||
|
||
|
||
首先我们需要明白建模的目的是什么？如果仅仅是为了描画问题，那么并没有什么对错之分——仅仅是立场和角度的差别；而如果是为了企业业务系统而进行建模，那么这个问题应该变为：如何保证模型能够支撑企业的运营？
|
||
|
||
|
||
不要小看这个问题的改变，它实际上是对建模视角的调整与切换。从企业运营（注意，这里写到的是运营而不是运维，一字之差，天壤之别）的角度思考与识别模型，才是四色建模法的核心和精髓。这是我在请教了徐昊之后，再次阅读这篇文章后的一个体会。
|
||
|
||
如何理解四色建模法
|
||
|
||
徐昊认为，建立企业业务系统的关键目的是满足企业管理者和决策者的诉求。这个诉求就是满足对企业运营的需要。因此，针对企业业务系统建立的模型也需要满足这一诉求。用徐昊的话说，四色建模法并不是对领域建模，而是对企业的运营建模。企业的运营比领域更重要，也更加的稳定。
|
||
|
||
因此，理解四色建模法可以从小处说，就是从管理和运营的角度，抓住运营管理人员最为关注的基础和核心，即企业运营的基础：财务和会计。无论是法律上的诉求，还是财务管理的要求，核心的模型就是凭证。在四色建模过程中，我们识别出来的时标型对象，其实就是为此目的提供的一个个凭证。这些凭证以某种数据的形式留下足迹，并按照时间顺序排列起来，可以帮助我们追溯业务的运营或对财务的审计。
|
||
|
||
从大处说，就是从企业系统的“步速”策略来分析核心领域，即遵循 Gatner 提出的 Pace-Layered Application Strategy。这是 Gatner 在 2016 年提出的一份报告，它按照“步速”将企业的应用系统划分为三个层次：SoR（Systems of Record）、SoD（Systems of Differentiation）和 SoI（Systems of Innovation）。处于不同 Pace-Layered 的系统，构建目标并不相同，支持运营和管理的关注点也不相同，故而变化的速率也不相同，需要为其制定不同的企业架构策略，采用不同的技术架构、管理流程乃至于投资策略。这三个层次及其特征如下图所示：
|
||
|
||
|
||
|
||
（图片来自 Gartner）
|
||
|
||
说明：
|
||
|
||
Gartner 认为 SoR 的变化速率非常缓慢，系统运行的生命周期达到十年以上，充分体现了运营模式的不变性。这正是四色建模法善于解决的领域，也是它关注的核心。
|
||
|
||
当然，领域驱动设计也提倡对领域进行划分，将那些业务复杂且对系统成功具有关键意义的内容归入核心领域（Core Domain），作为系统最有价值的部分。Eric Evans 建议：“为了使领域模型成为有价值的资产，必须整齐地梳理出模型的真正核心，并完全根据这个核心来创建应用程序的功能。……让最有才能的人来开发核心领域。”
|
||
|
||
但是，四色建模法与领域驱动设计对核心领域的判断标准并不相同。领域驱动设计是从价值的角度来划分核心领域和子领域，Eric 甚至认为：“如果某个设计部分需要保密以便保持竞争优势，那么它就是你的核心领域。”这是一种对领域的纵向切分。四色建模法则不然，它是从企业运营和管理的角度进行划分，可以认为是对领域的横向切分。因为企业运营贯穿业务流程的始终，只要业务动作产生的结果影响到企业的运营，都将作为一种财务的凭证而被记录下来，作为时标型对象加入到四色建模法获得的模型中。这种横向切分的方式，正好与 Pace-Layered 的分层原则契合。本质上，四色建模法获得的并非领域模型，而是企业运营模型。当然，我们也可以将企业的运营视为一种领域，那么企业运营模型也可视为是领域模型的一部分了。
|
||
|
||
四色建模法的演化
|
||
|
||
四色建模法基本继承了彩色 UML 架构型的划分，但它对于各个架构型却有自己独到的理解。整体来看，它特别强调了时标型对象的重要性，理清了角色架构型与描述架构型的模糊定义，让这两个架构型变得更为简单，容易识别。至于 PPT 架构型，在四色建模法中被命名为实体（Entity）。由于实体这一词语在软件行业中被广泛运用，在领域驱动设计中也有自己特殊的含义，为了避免混淆，也为了更容易理解，我仍然保留彩色 UML 的架构型定义。因此，四色建模法代表的领域对象类型分别为：
|
||
|
||
|
||
时标型（Moment-Interval）对象：具有可追溯性的记录运营或管理数据的时刻或时段对象，用粉红色表示
|
||
PPT（Party/Place/Thing）对象：代表参与到流程中的参与方/地点/物，用绿色表示
|
||
角色（Role）对象：在时标型对象与 PPT 对象（通常是参与方）之间参与的角色，用黄色表示
|
||
描述（Description）对象：对 PPT 对象的一种补充描述，用蓝色表示
|
||
|
||
|
||
四色建模法将时标型对象视为建模的起点，自然亦是搭建整个领域分析模型的骨架。这就像八股文的破题，要是题意理解偏了，纵使整篇文章起承转合一气呵成，文字写得花团锦簇，最终也只能是名落孙山的下场。寻找时标型对象，就是破题。那么，什么才是时标型对象呢？
|
||
|
||
时标型对象
|
||
|
||
仍然在《运用四色建模法进行领域分析》这篇文章，徐昊谈到了自己对时标型对象的理解：
|
||
|
||
|
||
任何业务事件都会以某种数据的形式留下足迹。我们对于事件的追溯可以通过对数据的追溯来完成。……（我们虽然）无法回到从前去看看到底发生了什么，但是却可以在单据的基础上，一定程度地还原当时事情发生的场景。当我们把这些数据的足迹按照时间顺序排列起来，我们几乎可以清晰地推测出这个在过往的一段时间内到底发生了那些事情。
|
||
|
||
|
||
为什么在企业业务系统中需要记录这些业务事件呢？为什么我们需要对这些事件进行追溯呢？目的就是要支撑企业的管理和运营，这事实上也是我们开发企业业务系统主要解决的问题域。这就给了我们以启发，那就是在进行领域分析建模时，要从运营管理的角度去建模，从而建立一个能够支撑企业运营和管理的模型，而时标型对象就是模型中的关键概念。因此，我们需要抓住时标型对象的特征：
|
||
|
||
|
||
时标型对象是支撑运营体系关键流程的执行结果；
|
||
时标型对象是过去某个时刻或时段发生的事实（Fact）；
|
||
时标型对象记录的数据是决策者和管理者关注的信息，满足对责任的可追溯性；
|
||
时标型对象记录的数据是为了满足财务和法律的需求，倘若缺失，会影响到参与方的权益和义务。
|
||
|
||
|
||
虽然四色建模法以时标型对象为建模的起点，但并非说明时标型对象最容易发现和识别；恰恰相反，比诸于 PPT 对象或角色对象，这些时标型对象往往隐藏领域逻辑中，不易被人发现。之所以要以时标型对象作为建模的起点，是因为它们恰好构成了整个领域分析模型的骨干，属于领域分析模型中的核心概念，不可缺失。
|
||
|
||
在寻找和识别时标型对象时，我们需要理解什么是“对管理与运营产生影响”。以乘坐公交汽车为例。从前乘坐公交汽车时，是有售票员售票的。乘客掏钱买票，售票员就需要把车票撕下来给乘客，同时留下票根。这个票根会作为财务结账与审计的重要凭证。记得在有些公交汽车上还贴有“售票员收钱不撕票属于贪污行为”的标语。这个时候的公交车票就属于时标型对象。当公交汽车渐渐普及为无人售票后，乘客买票的行为为刷卡所代替，没有乘车卡的乘客则以自动投币作为乘车的支付行为。为了减轻运营成本，公交公司以刷卡交易记录和投币箱中的币值金额作为结账和审计的凭证，公交车票仅仅作为乘客的报销凭证，由乘客自行决定是否需要。此时，公交车票就不再属于时标型对象了。原因就在于它对公交公司的管理与运营没有影响。
|
||
|
||
当然，我们也不要忘记时标型对象的特征属性，那就是时刻与时段。因此，在寻找时标型对象时，可以首先建立一条时间轴。任何一个业务流程，都会随着时间的推移连续产生不同的事件。根据运营或法律的需求，我们需要记录下这些事件的足迹，形成可追溯的记录。倘若这些记录是决策者和管理者关注的信息，缺失它们会影响到对责任的追溯，就可以将其识别为时标型对象。
|
||
|
||
例如，6 月 7 日，咨询师肖然接受了一个工作任务安排，要求在次日从成都出差到北京。于是，肖然需要预订去程的机票。以下是按照时间线记录下来的肖然在某旅行网站上留下的足迹：
|
||
|
||
|
||
6 月 7 日 16 时 30 分，他使用自己的账户名登录到一家旅行网站：发起登录请求，输入密码后登录成功。登录请求与企业运营和管理无关，不需要识别为时标型对象。
|
||
6 月 7 日 16 时 32 分，他查询了 6 月 8 日从成都到北京的航班：发起航班查询请求，获得航班查询结果。航班查询结果与企业运营和管理无关，不需要识别为时标型对象。
|
||
6 月 7 日 16 时 40 分，他选定查询结果中的一个航班为去程，在输入乘客信息后并确认订单信息后，发起支付：提交机票预订订单，产生订单支付凭证，旅行网站向航空公司发起航班预订。订单、支付凭证影响到企业的财务和账目，航班预订影响到乘客的权益，直接或间接影响到了企业的运营和管理，识别时标型对象 Order、Payment 和 FlightSubscription。
|
||
6 月 7 日 17 时，旅行网站通知旅客订票成功：发送订票成功的通知信息，旅行网站完成订票支付交易。订票成功的通知信息与企业运营和管理无关，但机票会影响到乘客的权益，支付交易会影响到企业的财务账目，直接或间接影响到企业的运营和管理，识别时标型对象 AirTicket 和 Transaction。
|
||
6 月 7 日 18 时 20 分，因为行程有变，他取消了航班：取消订单并发起退款请求。订单状态变更影响到乘客和航空公司的权益，退款请求影响到企业的交易账目，直接或间接影响到企业的运营和管理，识别时标型对象 Order 和 RefundRequest。
|
||
6 月 7 日 18 时 22 分，旅行网管理员审核退票请求，审核通过并发起退款：取消订单的审核记录和退款记录影响到企业的审计与财务账目，直接或间接影响到了企业的运营和管理，识别时标型对象 Approvement 和 Refund。
|
||
6 月 7 日 18 时 23 分，订单取消成功：订单的状态变更影响到乘客和航空公司的权益，间接影响到企业的运营和管理，识别时标型对象 Order。
|
||
6 月 7 日 18 时 30 分，退款成功：退款操作为旅行网站与支付中介之间的一次交易，影响到乘客和企业的权益与财务账目，直接影响到企业的运营和管理，识别时标型对象 Transaction。
|
||
|
||
|
||
整条时间轴需要记录的数据如下所示：
|
||
|
||
|
||
|
||
通过时间轴识别时标型对象的关键有两点：
|
||
|
||
|
||
根据某个时刻产生的业务动作，去寻找与该业务动作具有因果关系的领域对象。例如，在“确认订单并支付”这个业务动作中，订单的确认动作会导致订单对象 Order 的产生，而支付行为又会产生 Payment 对象。虽然是订票，但由于旅行网站并不真正具备航班票务购买的能力，仅仅是一个订票中介，因而需要发起对该航班的预定信息，从而识别出 FlightSubscription 对象。既然旅行网站并不能确定订票是否能够购买成功，因而在乘客发起支付时，并没有发起与银行或第三方交易机构的交易，故而 Transaction 对象是在订票成功之后才产生的。
|
||
判断该领域对象是否直接或间接影响到企业的运营和管理，从而确定是否为时标型对象。例如，登录和查询航班的行为虽然会产生登录信息和航班查询结果，但由于这些信息并不会影响到企业的运营和管理，因此不被识别为时标型对象。注意，搜索请求 SearchRequest 与退款请求 RefundRequest 之间的区别。缺失后者可能导致退款失败，就会影响到乘客的合法权益，丧失了责任追溯的能力。再次强调，我们要区分运营和运维的区别，前者面向的是管理者和决策者，后者面向的是 IT 系统的运维人员。这实际上也是可追溯事实和日志的差别，前者是运营角度需要记录的信息，后者是运维角度需要记录的信息，二者不可等同视之。
|
||
|
||
|
||
虽然时刻和时段是时标型对象的特征属性，但是在四色建模法中，不能因为一个对象具有时间属性，就想当然地认为它是时标型对象。例如，航班 Flight 虽然具有计划起飞时间和计划降落时间、实际起飞时间和实际降落时间这两个时间段，但该时段属性与订票的业务活动并没有任何因果关系，并不会对企业的运营和管理产生影响，因而不属于时标型对象。实际上，它是与时标型对象相关联的 PPT 对象。
|
||
|
||
四色建模法的建模过程
|
||
|
||
四色建模法不仅进一步明确和简化了彩色 UML 提出的四种架构型对象，还总结了清晰的建模过程。在领域分析建模过程中，不是胡子眉毛一把抓，将所有类型的领域概念一股脑儿呈现出来，而是草蛇灰线，沿着一条若隐若现的建模路径由简至繁逐步显现模型的全貌。这条建模路径就是四色建模法的建模过程，它分为如下步骤：
|
||
|
||
|
||
首先以满足管理和运营的需要为前提，寻找需要追溯的事件。
|
||
根据这些需要追溯，寻找足迹以及相应的时标型对象。
|
||
寻找时标对象周围的参与方/地点/物品。
|
||
从中抽象角色。
|
||
把一些信息用描述对象补足。
|
||
|
||
|
||
四色建模法需要寻找追溯的事件，这与事件风暴的分析过程接近。事实上，二者在领域分析建模的活动中可以有机地融合。当然，由于时标型对象是支撑运营体系关键流程的执行结果，我们也可以事先确定系统的业务流程，然后寻找那些支撑运营体系的关键业务步骤。如下图所示的业务流程图，其中被标记为灰色的业务步骤就是我们识别时标型对象的关注点。针对这些业务步骤，从管理者或决策者的角度分别对它们提出以下问题：
|
||
|
||
|
||
该业务步骤是否核心步骤？
|
||
业务步骤是否产生值得记录的可追溯结果？
|
||
倘若缺失该结果，会影响运营或管理吗？
|
||
|
||
|
||
|
||
|
||
一旦确定该业务步骤产生的结果，且判定该结果会影响运营和管理，就说明该结果就是我们希望寻找到的隐藏在业务逻辑背后的重要领域概念。我们需要为这个概念命名，名称必须符合统一语言。倘若统一语言并未包含该概念（大多数时候，正是如此），则它的发现将极大地丰富领域模型与统一语言。
|
||
|
||
寻找时标型对象是四色建模的起点，一旦确定了这些时标型对象，就建立了整个领域分析模型的骨干。时标型对象在模型中往往不是孤立的，会与代表参与方/地点/物品的 PPT 对象建立关联。这个过程是对领域分析模型的一种丰富与补充。例如，时标型对象机票 AirTicket 与 PPT 对象航班 Flight 和旅客 Passenger，倘若机票缺少 Flight 的航班号和 Passenger 的姓名与身份证号，机票就是无效的。由于 PPT 对象明确地表达了人、组织、地点和物品，因此也可以相对容易地在业务需求描述中寻找到这些概念。在确定时标型对象与 PPT 对象之间的关系时，同时也可以帮助我们验证识别的时标型对象是否合理。
|
||
|
||
寻找角色对象，往往从时标型对象与 PPT 对象之间的关系着手。这些角色对象相当于是 PPT 对象参与到业务流程中所戴的帽子。如时标型对象“促销记录”与 PPT 对象“员工”之间存在关联，但做出促销决定的员工其实是“市场人员”，它就是员工在促销流程中所戴的帽子。四色建模法的角色对象与彩色 UML 的角色构造型在概念和职责上完全相同，但四色建模法更加突出它在时标型对象与 PPT 对象之间扮演的作用。在领域模型中，它往往被放到二者的关联线上：
|
||
|
||
|
||
|
||
四色建模法的描述对象被限定为对 PPT 对象的描述。在已经确定了 PPT 对象的前提之下，我们只需要判断这些 PPT 对象是否还需要做进一步的说明。若需要，就引入对应的描述对象。例如 PPT 对象员工仅提供了员工的基本信息，那就由“员工详情”提供更加详细的信息：
|
||
|
||
|
||
|
||
在运用四色建模法时，固然时标型对象是建模的起点乃至核心，但在识别过程中，却不必纠结识别出来的概念究竟是否为时标型对象。若为此花费了太多建模时间，就有些得不偿失了。毕竟在领域分析建模过程中，进行分析建模的“初心”并非要识别出时标型对象，而是识别能够完整表达领域知识的领域概念！换言之，四色建模法是方法和过程，获得的领域分析模型才是我们的目标与结果。这与前述彩色 UML 的建模思路是一样的。
|
||
|
||
|
||
|
||
|