架构设计的目的
软件系统充满了各种不确定性，上下游关系复杂、在大型项目中涉及到的人很多。我们需要拆解业务目标、制定计划。软件架构是开发优秀软件的基础，同时也是同步团队认知、统一团队目标的重要方法。其次是将风险和复杂度提前暴露，减少开发中遇到的坑。通过合理的技术选择、系统组织和资源管理，以支持业务需求、保障系统质量、提升团队协作效率、管理技术风险、为未来高扩展性做铺垫。
架构设计师的主要职责
- 从工程角度定义问题
- 产品经理定义功能特性，架构师则需要定义系统的质量属性和影响架构设计的约束和特性。
- 把控大局
- 从全局角度考虑系统，不单单只处理技术问题，人员、过程、产品需求等等都会影响到最终交付的系统。
- 平衡
- 需要在成本和高可用性中做取舍。
- 需要在成本与实现优雅做取舍。
- 技术债务
- 所有的软件都一定会有技术债务，但我们需要知道如何分解技术债务，在大局的视角下将技术债务逐步解决掉。哪些应该现在立即要解决？哪些能在此次交付中解决？哪些能在未来的什么时候解决？甚至有时候需要引入债务来换取更快交付。
核心问题
- 利益的相关方是谁？
- 主要业务目标是什么？
- 项目整体解决方案是什么样的？
- 涉及到哪些技术？
- 团队现在有人员擅长哪些技术？
- 最大的风险是什么？如何克服？
核心思维
- 将大问题拆解为容易处理的小问题。
- 通过软件架构告诉大家如何系统工作，架构可以被拆解成多人协作完成的多个部分。
- 定义概念和词汇，大家统一认知方便沟通。
- 不仅关注功能特性，还需要考虑功能需求、成本、约束、进度、风险、团队能力、质量属性。
- 软件架构可以避免犯重大错误，无论为何把决策写下来经过详细的推敲能有效避免拍脑门带来的麻烦。
- 以人为本，我们应当关注最终帮助到的人、实现的人、测试的人、设计的人、协调的人等等。尊重大家，倾听大家的意图。
- 推迟决策，应当优先关注高优先级的质量属性，降低风险，其它决策都可以延后。
- 参考已有的案例。
- 尽可能降低风险，时刻考虑哪些地方可能出错、应该如何避免。
- 尽可能简化问题，减少涉及到的利益方、增加或减少约束条件、拆解为多个子问题等。
架构设计应当占据多少时间
20% 最好。在《 Architecting ：How Much and When》一书中，Barry Boehm证明了开发、架构设计、返工是构成项目工期的三个主要部分。返工包括弥补设计缺陷、重写代码、改正错误等。要找到最佳平衡点，必须整体考虑设计成本，以及为了完成系统不可避免的返工。
最佳平衡点主要由软件规模、需求变更、系统复杂度决定。Boehm证明随着架构规划时间的增加，返工量会逐步减少。图上方的实线是架构设计时间与返工时间之和。
在这个例子里，当用于架构设计的时间少于20%时，最终的项目工期随着架构设计时间的增加逐步减少，但边际收益在递减。随着架构设计时间的进一步增加，虽然返工量仍然会减少，但整个项目工期反而变长。Boehm还研究了随着系统规模变化，最佳平衡点的变动情况。这些数据可以用来评估你的架构设计时间是否在合理范围内。
这张图包含了一些重要信息，我们分析一下其中要点。软件系统越大，前期做架构设计的获益就越大。据Boehm研究，大型软件系统(一千万行代码左右)将37%的时间花在架构设计上是一个明智的选择。软件系统越小，做前期架构设计的获益就越小。据Bochm研究，小型软件系统(一万行代码左右)花在前期架构设计上的时间不应该超过5%。在某些情况下，与其投入大量时间做前期架构设计，不如直接重写小型软件系统。前期架构设计做得不够，要对后期返工做好心理准备。小型软件系统不做过多的前期架构设计可以缩短整体工期，但是返工还是不可避免的。对此要做好准备，设计上可能存在的变动应该在计划里体现出来。如果前期架构设计做得不够，系统越大，后期折腾返工的概率就越高。前期架构设计的投入越多，后期返工就越少。前期架构规划有助于减少错误，如果你更重视项目进度的可控性，而不在乎效率，可以多花时间做前期架构规划（哪怕是小型系统）。而对大型软件系统而言，前期架构规划是必不可少的。用系统规模来估计前期架构设计的工作量很方便，因为规模很容易衡量和预估。不过也有团队用系统复杂度来决定前期架构设计的工作量，毕竟大型系统可能很复杂，但并非所有复杂的系统都很庞大。而对于可以用常规解决方案处理的系统，即使规模很大也可以不做太多的前期架构规划。估计前期架构设计工作量的另一个考虑因素是需求波动。重大需求一旦发生变化，精心打造的计划也会泡汤。如果你预计系统需求有可能发生大的波动，那么么可以推迟做出关键决策，同时尽量采用轻量级的设计方法和文档。
设计原则
最小代价原则
尽可能在一开始的时候，作出正确的选择，因为一旦这个架构设计出现，后面的人很有可能不愿意为了更好的架构而改进，而是遵循已有的设计。最小意外原则好的设计应该避免意外，遵守通用的规范和习惯，代码也是。这些意外其实是软件架构和设计中的复杂因素。最小意外也就意味着尽可能的简单。
DRY原则（Dont repeat yourself）
重复是软件的原罪之一，“Dont repeat yourself” 告诉我们应该尽可能的消灭重复和冗余。重复使得软件的阅读，修改，测试变得复杂，消灭重复，是使软件变得简单的手段之一。单一职责原则从服务到代码中的类，都应当只负责单一的职责。每个服务只完成自己职责内的任务，对于不是自己职责的功能交给其它服务来完成。
闭包原则（CCP）
服务的闭包原则就是当我们需要改变一个微服务的时候，所有依赖都在这个服务的组件内，不需要修改其他服务。服务自治、接口隔离原则尽量消除对其他服务的强依赖，这样可以降低沟通成本，提升服务稳定性。服务通过标准的接口隔离，隐藏内部实现细节。这使得服务可以独立开发、测试、部署、运行，以服务为单位持续交付。单向依赖尽量不要有服务之间的环形依赖或双向依赖，原因是存在这种情况说明我们的功能边界没有划分清楚或者有通用的功能没有下沉下来。
服务拆分原则
采用的主要设计方法可以利用 DDD，DDD 的战略设计会建立领域模型，可以通过领域模型指导微服务的拆分，主要分四步进行：
- 第一步，找出领域实体和值对象等领域对象。
- 第二步，找出聚合根，根据实体、值对象与聚合根的依赖关系，建立聚合。
- 第三步，根据业务及语义边界等因素，定义限界上下文。
- 第四步，每一个限界上下文可以拆分为一个对应的微服务，但也要考虑一些非功能因素。
以电商的场景为例，交易链路划分的限界上下文如下图左半部分，根据一个限界上下文可以设计一个微服务，拆解出来的微服务如下图右侧部分。
了解需求
- 可以建个表格确认每个利益相关方是谁、业务目标是什么、需求背景是什么。大多数系统只有三到五个目标，可以在记录目标时备注是【必须有】、【最好有】这样的标签方便后续设计时考虑进去。并且提前准备好问题，跟每个利益方聊聊。例子：
- 架构师：新系统上线后需要替换旧系统，什么时候处理旧系统呢？
- 利益方：新系统上线后会执行迁移计划，预计九个月完成。
- 架构师：预计什么时候完成所有迁移？
- 利益方：越早越好，最迟在明年 12 月完成。
- 架构师：那预计是明年三月底前就要上线。
- 利益方：是的。
- 架构师：关于迁移需求可以说得详细点么？
- 利益方：迁移前，新系统必须有这几个功能...
- 建立约束表格来限制设计，你可以区分出技术约束（如编程语言、操作系统、中间件）和业务约束（团队结构、进度和预算、法律限制等等），同时你需要明确提出方和背景。约束一旦确定，就不能讨价还价，应当与所有提出约束的提出方达成一致，约束是“必须这么做，否则项目会失败”而不是“尽量这么做”。
- 你可以从以下角度区分质量属性，并且给每个质量属性（可以重复）都写上对应的实际使用场景及优先级：
- 可修改性；
- 可维护性；
- 可服用性；
- 可测试性；
- 开发时间；
- 可用性；
- 可伸缩性；
- 性能；
- 可靠性；
- 安全性。
- 对功能需求进行分类：
- 画出架构草图。
- 对功能需求大致分类。
- 如果这个功能需求很有难度、有重大影响的可以单独一类。
- 寻找重要的、高优先级的一类。
- 对照架构草图，思考每个分类如何实现。
- 确立指标，可以拉上相关人一起参与:
- 在白板的最左侧写下目标
- 请参与者提出问题
- 研究每个问题，找出回答问题所需的指标
- 针对与现有问题或指标有关的其他目标，重复上述过程
- 确定计算指标所需的数据
- 确定从哪里可以获取所需数据（可以使用日志收集、Prometheus 收集、神策、埋点上报、谷歌分析等等都是可以的）
- 对指标和数据进行优先级排序
- 记录研讨会结果把上述的东西整理成文档。
建立领域模型
为了进一步简化架构设计中“模型”这个概念，直接使用 DDD 中的领域模型。 之所以不使用完整的 DDD 是因为 DDD 着实复杂、学习成本高、国内用的人少，为了方便大家快速上手只采用了一些 DDD 中的概念来辅助架构设计。
领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；领域模型是有边界的，只反映了我们在领域内所关注的部分。领域模型只反映业务，和任何技术实现无关；领域模型不仅能反映领域中的一些实体概念，如货物、书本、应聘记录、地址等；还能反映领域中的一些过程概念如资金转账等；可以想象成我们要开发一个学校管理系统。在设计这个系统之前，我们首先需要对这个学校的情况有一个大致的了解，比如学校有哪些人(学生、老师、校长等)，这些人可以做哪些事情(学生可以上课、老师可以教课等)。那么我们可以把学校这个领域中的基本概念和业务规则先抽象出来，做成一个模型，这就是领域模型。这个模型用简单易懂的语言描述了这个领域的主要元素和特征。之后系统开发人员就可以根据这个模型来设计系统的功能和数据库结构等，还可以和领域专家(比如学校老师)用这个模型来交流具体的需求。所以简单来说，领域模型就是先用简单的语言对需要开发的系统的主题做一个概括性的描述和总结。它是连接业务领域和系统设计的一个桥梁。明白了领域模型，开发系统就比较容易了。
下面是 Claude 生成的例子。假设我们要建立一个图书管理系统，领域模型可以包含:实体:
- 书籍(标题、作者、分类、ISBN等属性)
- 读者(名字、年龄、借阅历史等属性)
- 管理员(姓名、职位等属性)服务:
- 借阅书籍
- 归还书籍
- 续借书籍
- 缴纳罚金
- 采购新书规则:
- 每个读者最多可借5本书
- 借阅期限为20天
- 逾期未还，每天罚款1元
- 书籍采购budget每年1000元流程:
- 读者搜索书籍
- 读者借阅书籍
- 系统记录借阅信息
- 读者归还书籍
- 系统核算罚金
- 管理员采购新书图表形式的参考例子：
在初步建立规范的架构设计阶段，没必要在人少的时候大规模引入 DDD 的一堆概念，建立领域模型时最重要的是建立实体和领域服务还有它们之间的关系。初期的时候可以不用一口气把全部定得非常细，逐步完善即可。
确定架构模式
常见的架构模式现在并不多，选择合适的即可。
架构设计研讨会
- 将上面准备好的关键需求、约束等展示给团队。
- 介绍目标和背景。
- 参与者用 5-7 分钟画出架构设计草图。
- 展示草图并且游说其它人解释自己的设计如何满足目标。分享时不进行提问。
- 都展示完成后再进行提问。
- 如果有足够的时间，修改设计、再次展示、游说、提问循环。
架构设计图画法
C4 模型是一种轻量级的软件架构图的表示法，旨在帮助团队更好地理解和沟通软件架构设计。
C4代表了四个层次的抽象化，即：
- 上下文（Context）：上下文层次主要描述了软件系统与外部系统或人员之间的交互关系，其目的是为了提供软件系统的背景和整体结构。
- 容器（Container）：容器层次描述了软件系统中的容器（如服务器、数据库等）以及它们之间的关系，其目的是为了提供软件系统内部的大体结构。
- 组件（Component）：组件层次描述了容器内的组件（如Web应用程序、服务、数据库架构等）以及它们之间的关系，其目的是为了更细致地了解软件系统的内部组成。
- 代码（Code）：代码层次描述了组件内的代码实现，其目的是为了帮助开发者更好地了解组件的实现和技术细节。
如上图所示，这四个层次对应着从高到低的不同的抽象程度。对应到软件系统中来说，就是能够从不同的层级视图上，展示软件的架构，使得设计者和开发者们可以更好地理解、交流架构设计，并推进架构的演进升级。
第1级
系统上下文图系统上下文图是软件系统设计的起点，是让你后退一步以看到大的视角。画一个图表，将你的系统显示为中心的一个盒子，周围是展现的主要是两类信息：
- 本系统的用户是谁；
- 本系统如那些外部系统有交互。细节在这里并不重要，因为这是你缩小的视图，显示了系统全景的大图。重点应该放在人(参与者、角色、角色等)和软件系统上，而不是技术、协议和其他低级细节上。这是一种可以展示给非技术人员的图表。
- 呈现范围：单个软件系统。
- 主要元素：范围内的软件系统。
- 支持元素：在范围内直接连接到软件系统的人员(例如用户、参与者、角色或角色)和软件系统(外部依赖项)。通常，这些其他软件系统位于您自己的软件系统的范围或边界之外，您对它们没有责任或所有权。
- 目标受众：每个人，包括技术人员和非技术人员，软件开发团队内外的人员。
- 注意：推荐推荐给大多数团队。
第2级
容器图此处的容器，不是指Docker的一个容器。而是类似于服务器端web应用程序、单页应用程序、桌面应用程序、移动应用程序、数据库模式、文件系统等。本质上，容器是一个单独的可运行/可部署单元(例如，一个单独的进程空间)，用于执行代码或存储数据。系统上下文图将本系统看作一个黑盒，那么容器图则是把这个黑盒打开，深入到了软件的内部，展示了软件内体系结构的高级形状，以及职责如何在其中分布。
它还展示了主要的技术选择以及容器之间如何通信。这是一个简单的、以技术为重点的高级图表，对软件开发人员和支持/操作人员都很有用。
- 呈现范围：单个软件系统。
- 主要元素：范围内软件系统中的容器。
- 支持元素：直接连接到容器的人员和软件系统。
- 目标受众：软件开发团队内外的技术人员;包括软件架构师、开发人员和操作/支持人员。
- 注意：推荐推荐给大多数团队，该图没有说明部署场景、集群、复制、故障转移等。
第3级
组件图组件图，则是进一步放大并分解了每一个容器，接下来，您可以放大并进一步分解每个容器，以识别容器内的主要结构构建块，及其互相之间的交互关系。组件图展示了容器是如何由许多“组件”组成的，每个组件是什么，它们的职责和技术/实现细节等。
- 呈现范围：单个容器。
- 主要元素：范围内容器中的组件。
- 支持元素：容器(在软件系统范围内)加上直接连接到组件的人员和软件系统。
- 目标受众：软件架构师和开发人员。
- 注意：不推荐给大多数团队，如果你觉得组件图增加了价值，那么只创建组件图，并考虑为长期存在的文档自动化创建组件图。
第4级
代码结构图如果需要深入到组件代码层面，代码结构图可以显示组件是如何作为代码来实现的。主要是使用使用UML类图、实体关系图或类似的方法。
理想情况下，这种底层细节的图表，将使用工具(例如IDE或UML建模工具)自动生成，应该考虑只显示那些，你想要重点关注的属性和方法。所以，除了最重要或最复杂的组件之外，不建议使用这种详细级别。
- 呈现范围：单个组件。
- 主要元素：组件作用域中的代码元素(例如类、接口、对象、函数、数据库表等)。
- 目标受众：软件架构师和开发人员。
- 注意：不推荐用于大多数团队，对于长期存在的文档，大多数IDE工具都可以按需生成这种级别的详细信息。
使用C4模型的6个注意点
在团队架构中，使用C4模型来呈现架构视图时，需要注意以下几点：
- 目标清晰：在绘制C4模型之前，应该明确需要建模的系统、软件或架构的目标。确保每个层次上的图表都有明确的目的，能够传达给观众或其他利益相关者有关系统或软件的信息。
- 约定标识符：在绘制C4模型时，应使用一致的标识符来命名和标识不同的元素，例如系统、容器、组件和代码等。这有助于提高模型的可读性和理解性。
- 简单明了：C4模型强调简洁、清晰的表述。在绘制C4模型时，应避免使用过多的细节或技术语言，以确保每个层次上的图表都易于理解。
- 易于更新：C4模型应该能够随着时间的推移而更新，以反映系统或软件架构的演变。在绘制C4模型时，应该考虑如何使其易于维护和更新。
- 适度细节：在绘制C4模型时，应考虑到每个层次上需要展示多少细节。如果图表过于复杂，可能会导致人们难以理解和使用。
- 迭代性：C4模型是一个迭代的过程。在实践中，您可能需要多次绘制和修改C4模型以满足需求，并使其更好地反映系统或软件架构。总之，C4模型是一种简单但强大的建模方法，可以帮助您建立清晰、易于理解和易于维护的软件架构图表。通过遵循上述建议，您可以更好地使用C4模型来设计和描述复杂的软件系统。
实践中常见的6个误区
在使用C4模型时，可能会遇到一些常见的误区。以下是一些常见的误区，以及如何避免这些问题的方法：
- 过度关注细节：C4模型旨在提供一个高层次的概述，以帮助人们理解系统或软件架构。因此，过度关注细节可能会使模型过于复杂，难以理解。建议在模型的每个层次上保持适度的细节，以便读者可以轻松理解。
- 忽略系统间的交互：C4模型强调系统的上下文视图，但有时候人们可能会忽略系统之间的交互。在建模时，应该考虑系统之间的交互以及它们如何在软件架构中发挥作用。
- 忽略时间和演变：C4模型应该是可演化的，这意味着模型应该能够反映软件架构的演变。在建模时，应该考虑如何使模型易于更新和维护，以便反映软件架构的演变。
- 与UML混淆：虽然C4模型和UML有些相似之处，但它们是不同的建模方法。C4模型的重点是软件架构，而UML的重点是面向对象的编程。因此，建议不要将C4模型与UML混淆。
- 未充分考虑受众：C4模型的目的是使软件架构易于理解。因此，在绘制模型时，应该考虑模型的受众群体，并为他们提供足够的上下文信息和详细说明。
- 忽略安全和性能：在建模软件架构时，应该考虑安全和性能方面的因素。这些因素对系统的设计和实现都有重要影响，因此应该在C4模型中考虑它们。
架构决策记录
有时候我们更关心架构决策背后的动机有个关于架构设计的玩笑是，没有什么问题是不能用两个框加一条连线解决的，如果有的话，那就再加一个框和一条连线。确实架构师们经常用框和连线来表达架构决策是什么。但有时候我们更希望理解这个决策的前因后果，尤其是那些正因为这个历史决策承受痛苦的人。如果我们不理解这个历史决策背后的动机，那么我们只有两个选择：
闷头接受这个决策
如果这个决策的上下文没有变化，这个选择可能没有问题。但如果这个决策的上下文已经改变了，可能我们错过了一个调整决策的机会。我很怀疑，如果我们不理解某个决策背后的动机时，是否真得能在实际工作中贯彻这个决策，不会走样。
闷头绕过这个决策
同样的，如果这个决策的上下文已经失效了，那么绕过它可能没有问题。但另一种可能即我们在无意间把事情搞砸了。因此，这两个选择都不是好主意。那么我们如何穿越到历史决策制定的时间线去一窥背后的动机呢？还是得靠文档，我们称之为架构决策记录（Architecture Decision Record，简称ADR）。
架构决策记录应该包含什么
在网络上，可以找到各种各样的架构决策记录模板，那么架构决策记录应该包含什么呢？既然记录架构决策的动机是为了理解该决策背后的动机（好拗口），那么我们应该将更多的笔墨放在Why & What上。本着精简文档的原则，我认为架构决策记录至少应该包括以下几项：
问题描述
描述要解决什么问题以及为什么是现在这个时间点来解决这个问题
约束
描述在解决该问题时有什么限制条件，例如预算/时间线/资源
假设
描述在做出决策时带着什么假设，由于各种原因在决策当时，尚无法验证
相关的架构决策/原则
列举相关的架构决策或架构原则，它们也有助于帮助读者理解决策推导过程
备选方案
一组备选方案，如果有人总是问“你们有没有考虑过这种方案”，那么这里是回应的好地方。每个备选方案除了方案本身的描述外，还应该说明如果选择了该方案会有什么后果/代价
决策
最终选择了哪个备选方案，其后果/代价是什么
状态
草稿/待评审/已通过，可以根据你所在组织的架构决策流程来定义
架构决策记录应该保持什么粒度
那么什么样的决策适合以架构决策记录的形式来记录呢？这个需要根据你所在组织的情况来定，但原则上太细粒度的设计决策或太宏观的方向决策都不太适合。但不管什么样的决策，其背后的动机都值得记录下来，只是未必以架构决策记录的形式而已。例如，需要新增一个API或是修改已有的API，那么通过代码的提交备注就能记录了。而引入中台架构则太宏观了，可能需要一个报告来能说清。
架构决策记录应该存放在哪
原则上，架构决策记录应该尽可能开放，这样才能最长程度避免“有时候我们更关心架构决策背后的动机”中出现的闷头干的情况。所以不管是直接放到Wiki上，或是放在共享文件夹里，都需要将如何在避免泄密（如果有的话）的前提下，最大化读者可见性作为考量之一。另外，应该考虑将架构决策记录纳入配置管理（指保存历史版本），某些 Wiki（例如 Confluence 自带历史版本功能），或者采用普通文档（是类似于 Markdown 的普通格式，而不是二进制的Word文档，以便更方便的观测修订历史）搭配源码工具（Git/SVN等）。我们可以先放在飞书项目。
一个例子
下面我将用一个虚拟的例子来演示一个架构决策记录，我不会对其做背景介绍，请帮我验证一下这个架构决策记录能否达到它应有的作用。
标题: ADR-34-初步建立在线收款能力
问题描述
我们是一家依赖经销商分销的企业，现在正在尝试将指定商品直接向消费者销售，这要求我们为之建立在线收款的能力。
假设
- B2C试点业务只需要支撑付款，而不包含退款、订单二次收款等功能
约束
时间约束：B2C试点项目预计于20年9年上线运行，期间大约有2周的时间完成与在线支付供应商的集成。
业务约束：需要保障财务对账工作可以某种方式进行。考虑到B2C试点业务的计划，对账工作未必需要以自动的方式执行。
相关的架构决策/原则
根据ADR-32-引入在线支付供应商，为尽可能以最小的代价，支持多种支付方式，我们会与一家在线支付供应商合作，但商务协商仍在进行中。
备选方案
O1 由结账组件直接与在线支付供应商集成
- 由结账组件与在线支付供应商集成
- 由“结账单”业务实体负责兼顾在线收款的生命周期优势:
- 由于B2C试点业务只需要支撑付款，而不包含退款、订单二次收款等功能，因此，在线收款的生命周期与结账单的生命周期有较大重合。这种重合可以降低初始的工作量。劣势:
- 可以预见，将来会有更多需要在线收款能力的场景，这些场景未必是基于结账单工作的。因此从长远看，并不适合由结账组件来提供线收款能力影响:
- 如果选择该备案，可以预见在将来需要通过重构迁移至O2
O2 引入专职的在线支付组件与在线支付供应商集成
- 引入在线支付组件与在线支付供应商集成
- 引入“在线收款”业务实体负责管理在线收款的生命周期优势:
- 独立的“在线收款”实体可以将在线收款的生命周期与结账单的生命周期解耦，使其可以更容易扩展将来对订单二次收款等特性的支持劣势:
- 需要额外一名工程师投入，但目前已无足够人手
决策
从长远来看，O2是更好的选择，但我们目前需要在没有足够的工程师的情况下满足非常有挑战的项目时间线。因此建议先采用O1，在需要引入订单二次收款能力时切换到O2。
状态
待评审
架构设计文档模板
这个模板比较多，建议参考：
或者搜索下相关的模板。
评估架构设计方案可以组建评估会，准备好打分表格。
我们需要先达成一致的认知：架构设计没有绝对的好坏，只有适不适合当前业务。
- 使用前面定义的质量场景和约束作为评估准则，可以打分 1-5。
- 对上面找到的系统关键指标进行评估，打分 1-5。
- 还可以使用风险数量、不确定问题数量、大家对某一问题的态度、完成时间、适应性、技术债务等进行打分。
- 满足成本要求或进度目标的可能性，打分 1-5。
- 团队的技术能力是否适配或者可以很快掌握，打分 1-5。
- 可以写出七个你不确定的问题的答案。
- 比如架构中的关系哪些是不知道的。
- 有哪些地方直觉上是你比较担心的？评估完之后确定后续行动要点同步给大家。
DDD 设计方法论
