领域驱动设计 DDD

（引用）2004 年 Eric Evans 发表 Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计），简称 Evans DDD。领域驱动设计分为两个阶段：

1. 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；

2. 由领域模型驱动软件设计，用代码来实现该领域模型；

由此可见，领域驱动设计的核心是建立正确的领域模型。

DDD 跟 Design Thinking 很像，但它更偏重于技术人员。从技术的视角，要跟业务建立统一语言，同样也要跟设计建立，否则仅仅依靠可视化的高保真图去构建数字化产品和服务是无法应对现实中的不确定性的。

个人观点：

领域驱动设计需要考虑一些现实项目的前置条件，如跨职能的流程是否界定，需求是否讨论充分，企业内部各个角色的关注点在系统中是否体现并确认，当前 scope 与远景目标的路线图是否理解一致。

如果这些前提条件都处于稳定，并妥善管理的状态，领域驱动能很好的划分子域与上下文，识别领域概念、实体、值对象、聚合根等等。

现实的条件是：客户可能不能完整、一致的表达需求。需求需要在不断地迭代中围绕价值，提炼关键概念，理顺关系与流程，识别边界。同时依靠设计思维，确认项目团队与客户对未来产品或服务有一致的价值理解；另外，由于项目围绕需求实现路线图的逐步进行，要为子域划分为更小粒度的子域预留空间。

为了更好的挖掘需求，可以按关注点逐个扫描避免遗漏，如：权限设计反映组织结构与变动，Analytics 仪表盘与 simulation 反映决策，个人隐私数据的流动反映 GDPR，等等。

中台架构

（引用）中台主要解决两个问题： 一是提升体验，二是降低成本。体验怎么提升呢？中台只是手段，中台的目的是支撑小前台， 通过改善前台来提升用户体验，通过梳理业务 SLA 沉淀到中台，以服务化的方式输出，确保最低服务体验标准。

成本如何降低？通过合并重组相似组织来降低，如果系统存在大量重复建设，就说明公司存在大量重复组织， 合并这些组织就能够降低成本，从而提升效能。也就是消灭“山头林立”的组织，拆除烟囱组织，来降本增效。

中台解决不了什么问题？总结下来，就是一句话：“ 中台适合做组合式创新，不适合做颠覆式创新。”

个人观点：

多数企业都会经历成长期、稳定期。在稳定期孕育新的增长极，如此反复前进。创新与降本永远是企业决策者的 2 个抓手，对于具体的部门而言，有的可能需要降本，有的可能需要放手抢占市场。

行业的不同，企业的 IT 部门的地位和职能也不同。

如何通过技术支持企业持续业务增长的同时保持较低的 IT 支出？在增长或者变化的过程中有没有不变量？

面对不确定性，个人觉得还是有不变量的。从业务上讲，企业始终有董事会、职能部门如制造、销售、采购、财务、人力；从信息角度来看，逃不掉资金、实物、信息（单据）的流转；从日常工作讲，始终有权限管理、数据存储（附件）。

与国外的同事相聊，中台的概念没有如此火热。当然，不是说不可以不做。合适的分寸需要把握，抽象的级别很重要。落地的时候可以优先考虑 hub scenario。

引用：

1：DDD 领域驱动设计基本理论知识总结https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html

2： 中台彻底搞砸了？下一站，小中台大前台

https://www.sohu.com/a/445821571_115128