TOGAF 对于架构师的职责定义是了解并关注实际上关系重大但未变得过载的一些关键细节和界面，具体包括：理解并解析需求，创建有用的模型，确认、细化并扩展模型，管理架构。

TOGAF 即 The Open Group Architecture Framework （开放组体系结构框架），是由致力于技术标准制定和推广的非盈利组织 The Open Group 制定的用于开发企业架构（Enterprise Architecture）的一套方法和工具。

业务架构师：负责客户诉求的实现、专注于业务逻辑、特定业务场景的客户实现

应用架构师：理解业务，梳理模型，设计模式，接口，数据交互等

系统架构师：服务器负载，可靠性，伸缩，扩展，数据库切分，缓存应用等

企业架构的推导方式

一个企业级的架构常用有两种推导结构，一种是自上而下的、另一种是自下而上的。比如一个针对企业或者是独立 BU 的架构大概率从顶而下的去推导的，如果具体业务中的某个架构可能就是自下而上的推导。

从企业级关注的重点与 IT 解决方案角度来讲，分为三个阶段：

第一个阶段：企业有了自己经营目标也就是战略。围绕经营战略是需要来看有什么样系统来支撑第二个阶段规划，针对经营战略与企业信息战略需要从业务架构角度、IT 架构更详细的规划与设计，这个阶段可以称为分析的阶段。在分析阶段顶层架构师角色对企业经营战略或信息战略抽象了结构化的描述，其它的架构师角色会继续对这些结构化的描述做进一步分解，其主要的是同归对业务需求的与流程的规划第三个阶段是设计交付可以称为 IT 解决方案， 在这个过程是要对分析阶段输出的领域模型、企业概念架构模型进行系统化、流程化的设计

领域模型

比喻一下：汽车生产过程中，其生产工人对自己的本质工作是非常熟悉的，这些工人通常都是只负责设计或生产某一个或几个零部件 ，不管是在岗位多少年，这些工人也无法从一个宏观角度去认识汽车的整个流程一部好的汽车，首先是产生于大脑，这就是原始模型，设计者会把汽车的构思记录下来，接下来就是设计过程。设计师会在设计的修改与完善上花费大量的时间，几个月到几年都是有可能的，直到解决完美的状态，这个状态就是设计的模型能够完全的反映人脑中所想的。

领域是现实中的一种事物，无法通过简单的键盘输入变成一种代码，需要对其进行领域抽象化。改造世界任何一个东西都是要先认知与学习。没有对其深入的准确、全面的认知，就无法提供一个正确的并能够解决问题的解决方法。

Eric Evans（领域驱动设计的创始人 Eric Evans） 告诉大家， 软件系统的复杂性来源于其所对应的领域， 领域知识的抽象和建模是构建复杂软件系统的基础步骤 。这一段与国内的许多‘”面向数据库建模的设计方法“ 显得格格不入。这里并不是挑起这两种方法的做对谁错， 但从实际的情况来看， 面向数据库建模的设计方法，隐藏了面向对象分析与设计的许多细节。

不管是在企业应用架构、中台架构中，都提到了领域模型，抽象业务并在领域内做复用。这些年一般的领域模型设计方法偏向 Eric Evans 的“Domain-Driven Design”又称为 DDD 设计方法。这种设计方法兼顾综合分析与设计的模型，需要考虑系统的边界：

帮助分析理解复杂业务领域问题，描述业务中涉及的实体及其相互之间的关系，是需求分析的产物，与问题域相关是需求分析人员与用户交流的有力工具，是彼此交流的语言分析如何满足系统功能性需求，指导项目后续的系统设计

所以 DDD 设计方法综合考虑了业务领域、IT 领域。DDD 鼓励我们接触到需求后第一步就是考虑领域模型，而不是将其切割成数据和行为，然后用数据库实现数据，用服务实现行为，最后造成需求的首尾分离。

一个交易支付清算业务领域建模

先来看一个普遍的在网上购买旅行产品的交易业务模型

流程

用户向业务线发起交易请求；业务线向支付中心发起支付请求支付中心接收到业务线请求后，向第三方支付公司或银行发起支付请求用户根据提示完成支付第三方支付公司或银行通过接口通知支付中心用户支付成功支付中心通知业务线支付成功结果业务线通知商户支付成功，商户进行出票

备注：在上面描述的这个过程中就暂时叫在线机票的支付领域模型

业务用户：

在线旅行的业务用户，在一次的购买机票的交易过程中涉及到的两个用户、一个平台，一个是机票的买方、一个是机票的卖方。

业务场景（非登录状态）：

用户在机票搜索页或选择页面通过会选择单程、往返、特价、日期、航班信息，页面会向机票搜索发起搜索请求服务，服务会返回机票的近七天价格信息。用户选择自己需要的预定信息，并填写乘机人信息、联系人信息、报销信息行程订单并发送给业务线的订单系统订单系统会检索商户提供的机票信息的数量信息是否完善并返回给订单系统订单系统会把确认信息前台返回给用户用户根据订单返回的状态选择借贷卡、支付平台方式进行支付用户得到支付返回结果

这个在线旅行的支付领域模型可以分为三部分

客户域：主要有用户、商户、航司

业务域：有虚拟商品、订单、给用户提供服务的产品

支付域：交易、支付、交易反作弊、余额、支付帐户、收银台、网关、清算、结算、账务等域

对于支付这个域还可以进一步划分二级域，例如

从支付二级领域模型来说分为五个部分的内容

用户域：主要有 支付的个人帐户、支付商户帐户

产品域：交易反作弊、余额支付、收银台、快捷支付、信用付、担保交易、代购、预授权、卡、退款

支付过程域：交易、支付

资金域 ：清算、结算、对账

网关域 ：银行、第三方支付、路由

这个二级的领域模型可以看的出来， 完整的支付域还是有非常复杂的。接下使用清算这个三级小领域模型进一步展开。

清算领域模型与简单拆解

先来看一个业务的案例可以了解一下什么是清算。

sample：

大家常用的是招商银行的卡(ps 此处不是做广告)，假设某个时间去了西部的个城市 ，刚好身上的现金用光了需要取现金， 在这个城市没有招商银行的网点，但是有建设银行的，所以只能在建行的 ATM 机插入招商银行的卡取了 1000 元。这个对取款者来说跨行取了 1000 元，被收取了 2 块钱的手续费。

从银行的业务来看：

建行 ATM 读卡读到了一个招商银行的卡，并且还有笔取 1000 元现金业务。此时建行的系统通过网络告诉招商，xxxx 卡的用户要取现 1000 元，判断下能给他吗？招商的反馈说，帐户够了可以扣 1000 元，建行你先垫上吧。建行 ATM 吐出 1000 元

此时取款者拿到现金，取卡结束并为当地贡献 GDP 去。此时在银行这个跨行取款因为从建行获取的现金， 此时在银行之间会有一个债务关系，建行欠招行 1000 元，在一个周期内两个银行这笔业务的资金清算后，这笔取款的银行之间的业务才真正的结束。

同理，在购买机票的时用户从选择支付到最后银行扣款返回支付成功，这个过程的清算流程如下

业务用户：

用户、商户在发起一笔支付、退款业务活动，可以无感知的完成资金支付。资金对账结算组可以更关注自己的部分业务，而不用关注更多的清算层面的东西，同时可以减少工作量。对于接入新的清算渠道、可以为借贷分离打下很好的基础、同时减轻支付中心的成本。可以顺利的完成资金的支付，此时清算在资金

业务场景：

清结算操作人员通过手动触发或定时功能获取充值回导的文件清算前置机通过接口握手银行通讯前置，请求文件银行返回文件，清算前置机把文件保存到本地，并将数据导入对应的表中执行对账，系统将表中的数据与清算指令表的数据进行比对，并返回对账结果

一个清算的生命周期：

这里先给出清算这块的领域模型，这个模型属于三级领域模型

实体模型：

如上图所示，清算命令的与清算文件是多对一的关系、核对处理过的清算命令与清算文件处理结果是多对一的关系。卡类型与清算结构产品是多对一的关系、卡账户类型与清算机构的产品是多对一的关系，除此之外的其它的都是一对一的关系。

统一语言：

统一语言是业务域中间比较重要的一个环节，常用的是 UML （统一建模语言）来进行描述。比如清算这块的从功能来看有五六个功能，清算文件管理、清算命令管理、内部服务管理（卡管理、协议管理、机构管理）、通讯前置、其它等。因为涉及到功能蛮多，作者只选择清算文件处理这个模块来做 UML 描述（为了保持书中的图的效果，我还是用 keynote 中的图示来模拟）。

关于清算文件处理可以有五个功能，分别是回导文件的获取、回导文件的解析、回导文件导入、回导文件对账、回导文件对账结果查看。作者给出这个业务的时序图，在对账需要在导入后进行触发，触发方式有两种分别是人工方式、系统自动方式，下图给出的时序图是自动方式。

系统触发可以配置成一个定时执行任务，这样可以把实时要做的事情变成异步确保会做的事情，将使用到定时预约的系统功能

有了用例图后在完成一个时序图：

维护人员或定时任务发起到会任务请求。清算文件处理会通过标准的接口通过前置机发出我要什么。前置机会向金融机构发起请求文件。金融机构会返回请求文件。前置机会保存文件。前置机给清算文件处理模块返回文件保存的路径与参数。清算文件处理模块会调用响应解析格式把数据文件导入到数据库中。维护员或定时任务返回导入结果是否有异常。当就绪后发起对账请求。执行对账、把导入的数据与清算命令数据对对账。返回对账结果信息，并进一步提升后续处理。

数据模型:

选择清算命令的一个接口依赖模型， 作为案例只放了几个字段或属性。

然后细化的就是接口（细节省略）

一个搞数据的人为什么要了解这些内容，因为在大数据建设阶段的主题域抽象设计，公共主题抽象设计，以及大数据建设的万能灵丹不停的螺旋重构中，掌握一些方法产出效果会更好。

作者：李博源 大数据领域一枚考古从业者。