领域驱动设计业务架构 与 业务中台的关系

Posted 2021-05-01 跳动的数据

首先来总体的认识下领域驱动设计、业务架构及业务中台的关系，从下图中可以看出，业务中台建设对它们是有依赖关系的，有点意思的是那两条连线是虚线，想说明的是在现有业务中台落地建设过程中，也许有的公司并没有真正有意识的和它们建起连接，有的是自底向上的方式，有的是自顶向下的方式。各有各的的道去驱动落地。

大部分公司落地还是直接重构已有的系统，这时候它们两个也许会发挥一定的作用，可以想想的。

但是有一种结局能够想到的是，业务中台做的不好会导致，前端业务线觉的这些不应该在中台做，即使做出来了，对内对外产生价值并不大。

对于业务中台，个人认为它就像所有的架构或者模式演进而来一样，它是一种解决当下状况的思想，就像定义的接口一样，具体的实现方式可以有很多种，无论是借助已有的经验，还是博取众家之所长创立新的招式，都是可以的。

说道的很多，行道的人很少。只有正心稳了，才能做好，也不要给自己设定局限性，也许你就是下一个...

下面介绍下DDD和业务架构相关的内容

1. TOGAF介绍

开放组体系结构框架（英语：The Open Group Architecture Framework，缩写：TOGAF）是一个企业架构框架，它提供了一种设计，规划，实施和管理企业信息技术架构的方法[2]。TOGAF是一种高层设计方法。它通常被建模为四个级别：业务，应用程序，数据，和技术。它在很大程度上依赖于模块化，标准化以及已有的，经过验证的技术和产品。

从上面的图和文字中去了解TOGAF是什么，思考与DDD、业务中台有什么相似之处，能否借鉴一些可取之处，作为落地一些原则或是标准推动业务中台落地。

2. 业务架构是什么

业务架构是战略、流程、组织等业务元素的结构化表达。以实现企业战略为目标，构建企业整体业务能力规划并将其传到给技术实现端的结构化企业能力分析方法。

3. DDD(领域驱动设计)

它是一种处理高度复杂域的设计思想，试图分离技术实现的复杂性, 围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演化等问题，从而控制软件演化的复杂度。团队应⽤它可以成功地开发复杂业务软件系统，使系统在增⼤大时仍然保持敏捷。

领域驱动设计的核心诉求

让业务架构和系统架构形成绑定关系，从而当我们去响应业务变化调整业务架构时，系统架构的改变是随之而发的。

为什么需要领域驱动设计

1. 领域专家和开发人员一起工作，这样开发出来的软件能准确的传达业务模型。

2. 打破业务是业务，技术是技术的现状，使业务与技术深度融合。

3. 知识的集中，确保软件知识并不是只掌握在少数人手中，使研发和业务人员都有提升。

4.设计就是代码，代码就是设计。

5.战略设计和战术设计。

只有重视领域模型,在领域模型中沉淀业务知识,才能与业务模型匹配,有效控制项目复杂度,达到高内聚低耦合,提升业务变化的响应速度

事件风暴梳理复杂业务

4.总结

很多人都在讨论业务中台的价值，各种不同的问题，到底该不该做，这些疑问是不是应该自己去深度的思考和探索找出自己的认知呢。

好像说到最后是不是也不知道关系是啥，欢迎留言讨论哈^_^。

---

最近刚看完一本书，觉的挺不错的，推荐给大家。

http://product.dangdang.com/27919782.html