复杂业务架构设计方法论的思考

复杂业务架构设计方法论讨论的是：如何将这个复杂的业务需求合理的分成多个部分，从而分而治之。

对应 ddd 的战略设计阶段，识别限界上下文，核心域，支撑域，通用域（这是目标）个人认为一个限界上下文中可以有多个域，只要它们的领域概念是一致的即可。例如：用户领域就可以是一个限界上下文。但其中包括会员用户核心服务、商户用户核心服务（这俩可能是一个核心域微服务）；用户运营域（支撑域）；文件服务域（通用域）

方法呢？自上而下的梳理需求，在这过程中初步的划分大的系统模块，识别大的实体，形成初步的限界上下文映射关系

进而再深入到每一个模块，拆解需求，识别实体、值对象，形成聚合，梳理实体动作

一个聚合或多个聚合形成领域，或是核心域；或是支撑域，这与聚合的业务逻辑是否为需求、模块的核心能力有关。

为什么？因为解决复杂问题的一个有效方法是将其分解为多个相对简单的问题，再将多个简单问题分解为标准化的问题，然后分别解决。如果不进行分解，这个复杂问题往往会让我们在解决过程中陷入困境，就算设计出了解决方案，也往往由于解决方案过于复杂导致团队的认知超载。在分解的过程中，标准化的问题有标准化的方案；我们关注的重点就转到那些特异化、个性化的问题。这可能就是我们业务、组织的核心竞争力。

某日思考于加班下班路上的地铁😳