领域驱动设计--业务架构映射为应用架构(五)

通过《多维度规划业务架构》，我们获得了由业务领域-业务组件-业务服务三个层次组成的业务架构。虽然是架构，但其本质仍然属于问题空间，其目的在于真实地探索问题空间，了解我们要解决什么样的问题。我们用到“分解”的方法，并非在解决问题，而是希望通过横向分层与纵向切分让问题空间变得更小，降低业务复杂度罢了。

这种分解层次体现为：

业务领域是对目标系统之系统范围进行划分，划分依据为价值高低
业务组件是对业务领域的划分，划分依据在于业务相关性
业务服务是对业务组件的划分，划分依据在于领域模型的知识语境

领域驱动进行的业务分解，既是对问题空间的探索，又自然地暗合确定解决方案的思路。由于有清晰的边界存在，这一做法并未混淆问题空间与解空间，却天然地搭建了一种映射方法，使得我们能够以较小成本将业务架构映射为IT架构中的应用架构。

映射体系如下图所示：

在图右侧所示的应用架构中，我旗帜鲜明地标记了前台、中台与后台，意味着我对应用架构的划分遵循了中台战略规划的思想。

我所理解的“中台”，满足以下定义：

中台是企业数字化转型的能力复用战略规划体系
中台是演进式的能力复用战略动态规划过程

显然，中台不是产品，也不是平台，而是一种规划体系。在企业架构的应用架构中，中台仅占据了中间代表了“能力服务层”的一部分，体现为由应用组件构成的能力中心。所谓的“能力复用战略动态规划过程”，就是在企业战略愿景的指导下，以能力复用为最终目的：

对于产品服务层，通过识别变化频率与复用粒度，逐步将前台的产品特性沉淀为可复用的业务能力中心
对于基础服务层，通过识别企业IT资产，逐步从后台的工具与框架中提炼出可复用的业务能力中心

换言之，中台不是独立的，随着时间的推移，应形成前台、中台和后台（统称为“三台”）职责之间联动；中台也不是静态不变的，同样随着时间的推移，三台的边界发生动态变化。

之所以要为应用架构建立中台，是以复用为目的，提升研发的效率和质量。能力中心的构成，使得整个企业的系统架构可以打破烟囱系统天然构成的壁垒，也有利于它的快速演化，适应企业高速发展的业务需要。

中台战略体系保留了前台，主要是为了适应创新型产品的演变。前台的设计属于产品思维的范畴，因为它牵涉到快速试错的成本，没有时间和成本考虑对复用能力的沉淀，然而，对于中台已经具备的能力中心，不妨取“拿来主义”的态度，直接复用。如此既保证了快，又保证了稳。

在我认为的“三台”中，后台并非基础设施，它同样属于业务范畴。从Pace-Layer Architecture的角度讲，后台提供的业务其区别主要在于它的变化频率更低，甚至可能几乎不变；从领域驱动设计的子领域角度讲，后台提供的业务更加通用，以至于考虑购买而非自己构建的方式实现。

如果后台稳定地提供了业务支撑，其收益高于维护成本，则不必一定要将其提炼为能力中心，甚至于它就是一个或多个相对独立而封闭的IT系统，对它的改造存在诸多阻力，改造成本极高，就得允许在企业IT系统生态中继续存在这样的遗留烟囱系统。

不管是前台的产品，还是中台的能力中心，抑或后台的工具或框架，其解决方案皆由应用组件构成，它由业务组件映射而得。本质上，业务组件与应用组件都是限界上下文，但前者对应的限界上下文只考虑了业务边界，后者对应的限界上下文在此基础上继续深化，分别考虑团队角度的工作边界和技术角度的应用边界，进一步梳理限界上下文的边界，使其与应用架构相匹配。为示区分，我将其命名为“应用组件”。

应用组件与限界上下文也有不同之处。在领域驱动设计中，限界上下文确定的是逻辑边界，而在应用架构中，还需要确定它的物理边界。物理边界的确定是从质量属性角度考虑的，例如对可扩展性、可伸缩性、低延迟、高并发的响应，技术栈的限制，资源独立性的要求，可以确定该应用组件究竟应定义为服务（Service），还是库（library）。

通常，中台能力中心的应用组件应考虑微服务化，后台工具或框架则不然，大多数时候，定义为库可能更合适。对于前台，可以考虑一个产品对应一个微服务，也可以考虑一个产品的特性对应一个微服务。这取决于前台产品的粒度。

业务架构中纯粹表达业务的业务服务，在映射到应用架构时，被定义为应用组件需要公开在外的服务接口，我将其称之为“服务契约”，目的是体现服务调用者与服务提供者之间的一种”契约“关系。

一个业务服务映射到解空间，会定义一个服务契约；反之，一个服务契约却未必对应问题空间的业务服务——因为业务服务中的一个执行步骤也可能映射为一个服务契约。应用组件之间存在协作关系，根据业务服务的定义，如果一个业务服务的某个执行步骤由另外一个应用组件提供，就需要将其定义为另一个服务契约，但它并非业务服务。例如，“提交订单”业务服务对应于订单应用组件，需要对外公开”提交订单“的服务契约；在执行提交订单的流程时，需要验证库存，该功能由库存应用组件承担。由于订单应用组件会调用它，因而需要对外公开”验证库存“的服务契约，但”验证库存“并非一个业务服务，如下图所示：

业务服务属于问题空间的范畴，服务契约属于解空间的范畴，如此才是合理的。

服务契约对应于我提出的《菱形对称架构》中的北向网关。若应用组件为服务，则对应远程服务；为库，则对应本地服务。它们都不属于领域层的内容。业务服务的需求表现为业务服务规约，它的输入成为领域分析建模的基础；服务契约需要构成菱形对称架构的角色构造型共同协作完成，利用服务驱动设计可以驱动出领域设计模型，进而对其进行建模实现。

从产品/能力中心/工具/框架到应用组件，再从应用组件到服务契约，都有领域驱动设计的对应模式或方法去实现，由此就能实现应用架构的真正落地。若按照中台战略思想规划应用架构，意味着中台的落地也有了可供参考的实现过程与方法。

当然，通常所谓的”中台“，都会建立双中台，即业务中台和数据中台。这里参考了领域驱动设计的方法，针对的是业务中台的落地，亦可以理解为是应用架构的微服务化。至于数据中台，它关注的是全域数据的生命周期管理、数据资产的梳理与建设、全域数据分析与数据智能挖掘的数据服务，其着眼点显然和业务中台有着天壤之别，需要另外的设计方法与实现手段。

❀❀❀

领域驱动设计--业务架构映射为应用架构(五)相关推荐

领域驱动设计（DDD）：分层架构的三种模式
DDD DDD(Domain Driven Design,领域驱动设计)作为一种软件开发方法,它可以帮助我们设计高质量的软件模型.在正确实现的情况下,我们通过DDD完成的设计恰恰就是软件的工作方式. ...
微服务架构与领域驱动设计应用实践
本篇文章一共分为三个部分,分别是微服务架构的演进过程.具体实践微服务的应用技术和领域驱动设计的意识转变.微服务架构已经渗透到互联网应用的方方面面,而领域驱动设计也逐渐被业界所接收. 微服务架构几乎都是 ...
一文看懂 DDD(领域驱动设计)、CQRS和Event Souring与分层架构
我最近开始学习领域驱动设计,CQRS和事件溯源. 到目前为止,我主要参与了使用"经典"N层/层架构和关系数据库的项目. 随着项目变得越来越复杂,我注意到这个模型并不总是很好. 不久 ...
如何使用ABP框架（2）三层架构与领域驱动设计的对比
本文来自长沙.NET技术社区,原创:邹溪源.全文共有8500字,读完需耗时10分钟. 题图来自@pixabay 简述上一篇简述了ABP框架中的一些基础理论,包括ABP前后端项目的分层结构,以及后端项 ...
c/s三层结构信息系统的三个层次_如何使用ABP框架（2）三层架构与领域驱动设计的对比...
本文来自长沙.NET技术社区,原创:邹溪源.全文共有8500字,读完需耗时10分钟. 题图来自@pixabay 简述上一篇简述了ABP框架中的一些基础理论,包括ABP前后端项目的分层结构,以及后端项 ...
如何使用ABP进行软件开发（2）领域驱动设计和三层架构的对比
简述上一篇简述了ABP框架中的一些基础理论,包括ABP前后端项目的分层结构,以及后端项目中涉及到的知识点,例如DTO,应用服务层,整洁架构,领域对象(如实体,聚合,值对象)等. 笔者也曾经提到,AB ...
在洋葱（Onion）架构中实现领域驱动设计
Wade Waldron是一位来自于BoldRadius的资深软件开发者,他在一次演讲中表示,他在几年前开始结合使用领域驱动设计(DDD)与洋葱架构,他的代码质量从此得到了极大的提高.一开始他仅仅使用 ...
何时使用领域驱动设计
何时使用领域驱动设计?其实当你的应用程序架构设计是面向业务的时候,你已经开始使用领域驱动设计了.领域驱动设计既不是架构风格(Architecture Style),也不是架构模式(Architectu ...
领域驱动设计和实践(转：http://kb.cnblogs.com/page/112298/)
引言软件系统面向对象的设计思想可谓历史悠久,20世纪70年代的Smalltalk可以说是面向对象语言的经典,直到今天我们依然将这门语言视为面向对象语言的基础.随着编程语言和技术的发展,各种语言特性层 ...

领域驱动设计--业务架构映射为应用架构(五)

领域驱动设计--业务架构映射为应用架构(五)相关推荐

最新文章

热门文章