编辑导语：领域模型是对领域内的概念类或现实世界中对象的可视化表示，它专注于分析问题领域本身。本篇文章中，作者分享了自己对领域模型的理解，感兴趣的小伙伴不妨来看看~
TOGAF对于架构师的职责定义是了解并关注实际上关系重大但未变得过载的一些关键细节和界面，具体包括：理解并解析需求，创建有用的模型，确认、细化并扩展模型，管理架构。
TOGAF 即 The Open Group Architecture Framework （开放组体系结构框架），是由致力于技术标准制定和推广的非盈利组织 The Open Group 制定的用于开发企业架构（Enterprise Architecture）的一套方法和工具。
一个企业级的架构常用有两种推导结构，一种是自上而下的、另一种是自下而上的。比如一个针对企业或者是独立 BU 的架构大概率从顶而下的去推导的，如果具体业务中的某个架构可能就是自下而上的推导。
从企业级关注的重点与 IT 解决方案角度来讲，分为三个阶段：
比喻一下：汽车生产过程中，其生产工人对自己的本质工作是非常熟悉的，这些工人通常都是只负责设计或生产某一个或几个零部件 ，不管是在岗位多少年，这些工人也无法从一个宏观角度去认识汽车的整个流程一部好的汽车，首先是产生于大脑，这就是原始模型，设计者会把汽车的构思记录下来，接下来就是设计过程。
设计师会在设计的修改与完善上花费大量的时间，几个月到几年都是有可能的，直到解决完美的状态，这个状态就是设计的模型能够完全的反映人脑中所想的。
领域是现实中的一种事物，无法通过简单的键盘输入变成一种代码，需要对其进行领域抽象化。
改造世界任何一个东西都是要先认知与学习。没有对其深入的准确、全面的认知，就无法提供一个正确的并能够解决问题的解决方法。
Eric Evans（领域驱动设计的创始人 Eric Evans） 告诉大家， 软件系统的复杂性来源于其所对应的领域， 领域知识的抽象和建模是构建复杂软件系统的基础步骤 ，这一段与国内的许多”面向数据库建模的设计方法“ 显得格格不入。
这里并不是挑起这两种方法的做对谁错， 但从实际的情况来看， 面向数据库建模的设计方法，隐藏了面向对象分析与设计的许多细节。
不管是在企业应用架构、中台架构中，都提到了领域模型，抽象业务并在领域内做复用。
这些年一般的领域模型设计方法偏向 Eric Evans 的“Domain-Driven Design”又称为 DDD 设计方法。这种设计方法兼顾综合分析与设计的模型，需要考虑系统的边界：
所以 DDD 设计方法综合考虑了业务领域、IT 领域。DDD 鼓励我们接触到需求后第一步就是考虑领域模型，而不是将其切割成数据和行为，然后用数据库实现数据，用服务实现行为，最后造成需求的首尾分离。
先来看一个普遍的在网上购买旅行产品的交易业务模型：
备注：在上面描述的这个过程中就暂时叫在线机票的支付领域模型
业务场景（非登录状态）：
这个在线旅行的支付领域模型可以分为三部分：
对于支付这个域还可以进一步划分二级域，例如：
从支付二级领域模型来说分为五个部分的内容：
这个二级的领域模型可以看的出来， 完整的支付域还是有非常复杂的，接下使用清算这个三级小领域模型进一步展开。
先来看一个业务的案例可以了解一下什么是清算。
大家常用的是招商银行的卡(ps 此处不是做广告)，假设某个时间去了西部的个城市 ，刚好身上的现金用光了需要取现金， 在这个城市没有招商银行的网点，但是有建设银行的，所以只能在建行的 ATM 机插入招商银行的卡取了 1000 元。这个对取款者来说跨行取了 1000 元，被收取了 2 块钱的手续费。
从银行的业务来看：
此时取款者拿到现金，取卡结束并为当地贡献 GDP 去。此时在银行这个跨行取款因为从建行获取的现金，此时在银行之间会有一个债务关系，建行欠招行 1000 元，在一个周期内两个银行这笔业务的资金清算后，这笔取款的银行之间的业务才真正的结束。
同理，在购买机票的时用户从选择支付到最后银行扣款返回支付成功，这个过程的清算流程如下
（1）业务用户
（2）业务场景
一个清算的生命周期：
这里先给出清算这块的领域模型，这个模型属于三级领域模型：
（3）实体模型
如上图所示，清算命令的与清算文件是多对一的关系、核对处理过的清算命令与清算文件处理结果是多对一的关系。
卡类型与清算结构产品是多对一的关系、卡账户类型与清算机构的产品是多对一的关系，除此之外的其它的都是一对一的关系。
（4）统一语言
统一语言是业务域中间比较重要的一个环节，常用的是 UML （统一建模语言）来进行描述。
比如清算这块的从功能来看有五六个功能，清算文件管理、清算命令管理、内部服务管理（卡管理、协议管理、机构管理）、通讯前置、其它等。因为涉及到功能蛮多，作者只选择清算文件处理这个模块来做 UML 描述（为了保持书中的图的效果，我还是用 keynote 中的图示来模拟）。
关于清算文件处理可以有五个功能，分别是回导文件的获取、回导文件的解析、回导文件导入、回导文件对账、回导文件对账结果查看。
作者给出这个业务的时序图，在对账需要在导入后进行触发，触发方式有两种分别是人工方式、系统自动方式，下图给出的时序图是自动方式。
系统触发可以配置成一个定时执行任务，这样可以把实时要做的事情变成异步确保会做的事情，将使用到定时预约的系统功能
有了用例图后在完成一个时序图：
（5）数据模型
选择清算命令的一个接口依赖模型， 作为案例只放了几个字段或属性。
然后细化的就是接口（细节省略）。
作者一个搞数据的人为什么要了解这些内容，因为在大数据建设阶段的主题域抽象设计，公共主题抽象设计，以及大数据建设的万能灵丹不停的螺旋重构中，掌握一些方法产出效果会更好。
作者：松子（李博源）
本文由 @松子 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。