架构设计之设计模型

Posted 2021-04-10 Jefferson零点工坊

    最近在工作中遇到一些棘手的问题，对架构设计方法重新梳理了一下，如下是根据多年积累、收集形成的，并非完全原创。

    软件如果没有良好的架构设计，在产品的第一版中你可能感觉不到它的太大问题，而且设置可能会觉得进度更快，成本更低。但如果你的产品需要在企业发展中不断持续迭代，增加新的功能，满足不同用户需求，你就会发现如果没有良好的架构设计，在后续开发中，一个简单功能的开发都会翻天动地，动辄几个人月的开发工作量，而且还会质量不稳定，不可控。并且随产品发展的时间周期加长，没有良好架构设计产品的单位功能开发成本程几何级数增长甚至3~5年以后，产品无法维护，必须重构。

    这就是为什么老板会觉得，产品开发感觉都差不多了，为什么会用人越来越多，总也稳定不下来的原因之一。下面我就从架构层面来聊聊。

    主流架构设计正在由集中式架构向分布式架构的技术转型，正如从盖砖瓦房向盖高楼大厦转变一样，必然要有组织、文化、理念和设计方法的同步更新，其中最不可或缺的能力就是架构设计能力。开门见山，先来看看目前主流的几种典型的架构模型。

 整洁架构

    此架构模型在《架构整洁之道》中有详细描述。顺便做个广告，《架构整洁之道》是一部很棒的架构书籍，介绍的不仅是整洁架构本身，而是架构设计的一些很棒的原则，建议大家购买。

    回来说整洁架构，在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务、最外围是容易变化的内容，如界面和基础设施（如数据存储等）。整洁架构是以领域模型为中心，不是以数据为中心。

 六边形架构（又名端口适配器架构）

追溯微服务架构的渊源，一般会涉及到六边形架构。六边形架构的核心理念是：应用是通过端口与外部进行交互的，这也是微服务架构下 API 网关盛行的主要原因。六边形架构中，内部业务逻辑（应用层和领域模型）与外部资源（APP，WEB 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错的主要问题，从而可以很好的实现前后端分离。

 领域驱动设计分层架构

DDD 分层架构各层定义与职能：

展现层：它负责向用户显示信息和解释用户命令，完成前端界面逻辑。这里的用户不一定是使用用户界面的人，也可以是另一个计算机系统。

应用层：它是很薄的一层，负责展现层与领域层之间的协调，也是与其它系统应用层进行交互的必要渠道。应用层要尽量简单，不包含业务规则或者知识，不保留业务对象的状态，只保留有应用任务的进度状态，更注重流程性的东西。它只为领域层中的领域对象协调任务，分配工作，使它们互相协作。

领域层：它是业务软件的核心所在，包含了业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系，负责表达业务概念、业务状态信息以及业务规则，具体表现形式就是领域模型。领域驱动设计提倡富领域模型，即尽量将业务逻辑归属到领域对象上，实在无法归属的部分则以领域服务的形式进行定义。

基础设施层：它向其他层提供通用的技术能力，为应用层传递消息（API 网关等），为领域层提供持久化机制（如数据库资源）等。

 架构模型对比和分析

虽然整洁架构、六边形架构以及 DDD 分层架构三种架构模型展现方式以及解决问题的出发点不一样，但其架构思想与微服务架构高内聚低耦合的设计原则高度一致。

整洁、六边形以及 DDD 三种架构模型关系

从上图可以看出，在六边形架构、DDD 分层架构的白框部分以及整洁架构 

最大的不同之处在于架构过程，整洁和六边形架构模型面向的是开发者，而DDD是面向从业务到开发全过程，项目详细介绍DDD的架构模型设计过程，对其他两种模型的应用也会有所启发。

领域驱动设计概述

      领域驱动设计（DDD）是一种处理高度复杂域的设计思想，试图分离技术实现的复杂性，围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演化等问题。团队利用它可以成功的开发复杂业务软件系统，在系统变大时仍能保持敏捷性。

领域驱动设计分为两个阶段：

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

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

    领域驱动设计的核心诉求是让业务架构和系统架构形成绑定关系，当我们去响应业务变化调整业务架构时，系统架构的改变也会随之发生。在领域驱动设计中业务架构的梳理和系统架构的梳理是同步进行的，其结果是设计出的业务上下文和系统模块结构是绑定的。同时技术架构也是解耦的，可以根据划分出来的业务上下文的系统架构选择最合适的实现技术。

领域驱动设计可能会给你带来以下收获：

1、领域驱动设计是一套完整而系统的设计方法，它能带给你从战略设计到战术设计的规范过程，使得你的设计思路能够更加清晰，设计过程更加规范。

2、领域驱动设计尤其善于处理与领域相关的高复杂度业务的产品研发，通过它可以为你的产品建立一个核心而稳定的领域模型内核，有利于领域知识的传递与传承。

3、领域驱动设计强调团队与领域专家的合作，能够帮助团队建立一个沟通良好的团队组织，构建一致的架构体系。领域驱动设计强调对架构与模型的精心打磨，尤其善于处理系统架构的演进设计。

4、领域驱动设计的思想、原则与模式有助于提高团队成员的架构设计能力。

5、领域驱动设计与微服务架构天生匹配，无论是在新项目中设计微服务架构，还是将系统从单体架构演进到微服务设计，都可以遵循领域驱动设计的架构原则。

基于 DDD架构模型设计方法简介

    这里只讲述基本的设计流程，详细设计方法需要参考专门书籍。

    DDD 设计包括战略设计和战术设计两个部分。在战略设计阶段主要完成领域建模和服务地图。在战术设计阶段，通过聚合、实体、值对象以及不同层级的服务，完成架构的的建设和实施。通过 DDD 可以保证业务模型、系统模型、架构模型以及代码模型的一致。

本部分主要讨论领域设计方法，如对战术设计和开发方法感兴趣可查阅 DDD 战术设计相关资料。

DDD 领域设计过程包括产品愿景、场景分析、领域建模和服务地图阶段，也可根据需要裁剪不必要的阶段和参与角色。领域驱动设计一般经历 2-6 周的时间，领域模型设计完成后，即可投入架构的实施。

1、产品愿景

产品愿景是对产品的顶层价值设计，对产品目标用户、核心价值、差异化竞争点等策略层信息达成一致，避免产品在演进过程中偏离方向。

• 阶段输入：产品初衷、用户研究、竞品知识和差异性想法 。

• 参与角⾊：业务需求方、产品经理、开发组长和产品发起人。

• 阶段产出：电梯演讲画布。

2、场景分析

场景分析是针对核心用户及顶层服务的一种定性分析，从⽤户视角出发，探索问题域中的典型场景分析。同时也是从用户视角对问题域的探索，产出问题域中需要支撑的场景分类及典型场景，用以支撑领域建模阶段。

• 阶段输⼊：核⼼干系人和服务价值定位。

• 参与角色：产品经理、开发组长和测试组长。

• 阶段产出：场景分类清单。

3、领域建模

领域建模是通过对业务和问题域进⾏分析，建⽴领域模型，向上通过限界上下⽂指导微服务的边界设计，向下通过聚合指导实体的对象设计。领域建模主要采用事件风暴方法。

• 阶段输入：业务领域知识和场景分类清单。

• 参与角色：领域专家、架构师、产品经理、开发组长和测试组长。

• 阶段产出：聚合模型和限界上下⽂地图。

4、服务地图

服务地图是整个产品服务架构的体现。结合业务与技术因素，对服务的粒度、边界划分、集 成关系进⾏梳理，得到反映系统微服务层面设计的服务地图。

• 阶段输⼊：限界上下⽂地图。

• 参与角⾊：产品经理、开发组长、测试组长和产品发起人。

• 阶段产出：服务地图。

在进行服务地图设计时需要考虑以下要素：1. 围绕限界上下⽂边界。2. 考虑不同业务变化速度 / 相关度、发布频率。3. 考虑系统非功能性需求，如系统弹性伸缩要求、安全性要求和可⽤性要求。4. 考虑团队组织和沟通效率。5. 软件包限制。6. 技术和架构的异构。

通过 DDD 战略和战术全流程设计可建立业务架构与系统架构的一一映射，保证业务和代码模型的一致性。

写在最后

    良好的架构设计优势明显，但也有问题，或者说代价。首先就是进度和成本的代价。

    我们的软件产品一般都会分为几个阶段，1、产品成型阶段，这个阶段可以作为商业用途，试探市场反应。2、发展阶段，如果发现产品OK，那么进入发展阶段，这阶段会拓展大量客户有大量需求，定制需求，A/B测试等等，这阶段的研发投入会远远高于产品成型阶段。3、维持阶段，市场走下坡路，无力回天，保持最低成本，获取最大投入产出比。

    良好架构设计的产品，在产品成型阶段中，成本投入一般会是没有良好架构设计的2倍，时间进度至少是1.5倍。而在发展阶段中，一般是没有良好架构设计产品的1/2,1/3,1/10，是随着产品发展的时间周期加长，没有良好架构设计产品的单位功能开发成本程几何级数增长，一般预计，3~5年以后，产品处于无法维护的阶段，必须重构才能解决问题。

    架构设计也需要企业具备一定的高度，如文化、组织和技术，需要企业有长远发展的眼光，如果高度不够，我们是否可以站在巨人的肩上呢？