夜雨聆风
核心梳理
1. 综合运用三大原则
将大型结构与BOUNDED CONTEXT结合使用：大型结构（如RESPONSIBILITY LAYER）横跨多个BOUNDED CONTEXT，为它们提供统一的“语法”或组织方式。而BOUNDED CONTEXT则定义了该结构应用的范围。两者结合，大型结构在所有上下文中保持一致性（如“决策层”在所有相关上下文中均处理策略决策），而BOUNDED CONTEXT则允许各自对“决策”概念有不同的具体化。 将大型结构与精炼（CORE DOMAIN）结合使用：大型结构应该专注于描述CORE DOMAIN。团队不应该在GENERIC SUBDOMAIN（如日志、报表）上使用大型结构，这会增加不必要的复杂性。大型结构是为了突出核心、指导核心的设计。
2. 首先评估
在实施任何战略设计决策前，必须做冷静的政策性评估，而不是“因为某个模式看起来很酷”就使用它。 评估工具：书中没有定义专门的表格，但提出了关键的评估问题框架（见下方的指导原则）。
3. 由谁制定策略
从应用程序开发自动得出的结构：有时，系统（特别是大型遗留系统）的结构并非设计出来的，而是从早期的应用程序开发中自然涌现的。团队应该识别这种已经被默许的结构，并将其提升为正式的、有意识的战略设计决策。 以客户为中心的架构团队：在一个大型项目中，需要一个由少数人组成的、紧密协作的架构团队。这个团队拥有决策权，负责制定和保持战略一致性。但他们的职责不是“凌驾于”开发团队之上，而是： 与开发团队沟通并解释战略决策。 确保战略决策在开发中得到体现。 倾听开发团队的反馩，当发现模型需要变更时，及时调整结构。
4. 制定战略设计决策的6个要点
决策要基于事实：基于具体的代码、具体的需求，而不是抽象的理论。 团队达成共识：决策必须是团队协商的结果，而非一个人的意志。需要通过UBIQUITOUS LANGUAGE来沟通。 关注核心：始终问“这个决策是否有利于简化我的核心模型？” 适应变化：战略决策并非一成不变，当模型理解加深时，需要勇敢地修改它们。 标准化上瘾：避免为了“标准化”而强制所有上下文使用相同的模式或结构。不同的上下文有不同的需求。 命名与边界：为你的BOUNDED CONTEXT、大型结构取一个好名字，并将这些名字纳入UBIQUITOUS LANGUAGE。
项目使用时的指导原则
1. 战略设计三大原则的协同效应：不要孤立使用任何一个 💡
原则：战略设计的三把斧头——BOUNDED CONTEXT（边界）、精炼（聚焦核心）、大型结构（导航）——必须协同使用，才能产生“1+1+1>3”的效果。 行动： 使用BOUNDED CONTEXT划定范围：首先，用BOUNDED CONTEXT将系统划分为逻辑上相互独立的模块。 在核心域上应用大型结构：只在CORE DOMAIN相关的BOUNDED CONTEXT内应用大型结构（如RESPONSIBILITY LAYER）。 使用精炼指导结构的演变：精炼（第15章）的结果——比如识别出CORE DOMAIN的子核心，或发现GENERIC SUBDOMAIN——将引导你应该在哪个位置应用哪类结构。结构服务于精炼，而非反之。
2. 在做任何战略决策前，先冷静地“首先评估” 📋
原则：不要出于“潮流”或“个人偏好”而引入一个模式（如“我们用事件驱动吧！”或“我们引入一个大的责任层吧！”）。每个战略决策都必须经过评估。 行动： 创建“决策影响分析”：在引入一个BOUNDED CONTEXT或一个大型结构前，团队花30分钟做一个“决策影响分析”： 当前问题是什么？ 当前设计中最困扰你的具体问题是什么？(如“模块A和模块B的依赖太混乱了”)。 预期的好处是什么？ 新引入的模式能解决这个问题吗？(如“分出一个Resposibility Layer能强制它们解耦”)。 预期成本是什么？ 引入新模式需要多少改动？会对其他团队产生什么影响？(如“这会影响团队B的集成代码”)。 有什么替代方案？ 有没有更简单的方法（如直接重构依赖关系，而不引入新模式）？ “先做最有价值的决策”原则：在6个要点的指导下，选择对项目当前威胁最大的一个方面来制定决策。不要在几周内同时制定所有战略决策。每次解决一个。
3. 组建一个“小型的、为决策服务的”架构团队 🏛️
原则：战略设计需要权威，但不是权力。需要一个由少数（2-4人）、最有见识的成员组成的架构团队来引导（而非“命令”）战略决策的制定和维护。这个团队是“以客户为中心的”，他们花时间去理解开发团队的工作。 行动： 人员构成：这个团队应该包括： 一位精通DDD战略设计的高级开发人员。 一位（或两名）对业务核心理解最深的领域专家。 一位有视图中的项目经理（如果需要）。 每周例会：架构团队每周与各开发团队的领导者（或代表）会面一次（30分钟到1小时）。会议的内容是：“战略设计是否仍在起作用？我们有没有遇到需要调整边界或大型结构的信号？” 明确的文档：战略决策（BOUNDED CONTEXT的定义、大型结构的选择、CONTEXT MAP）必须在团队的“知识库”中有一份清晰的、活着的文档。这个文档不是高深的架构文章，而是一张图 + 一句话描述。
4. 警惕“标准化上瘾”和“预先大设计” 🚫
原则：这是本章的一个核心警告。不要为了追求“架构的一致性”或“优雅的标准化”，而在一开始就制定一个“宏伟蓝图”。 行动： 允许混沌：初期的模型、BOUNDED CONTEXT甚至大型结构可以是不完美的。它们是“知识消化”的起点，而不是终点。 允许不同的上下文使用不同的语言/结构：如果一个BOUNDED CONTEXT非常简单（如只处理静态数据报表），不必强迫它使用与CORE DOMAIN相同的大型结构。不同的上下文，不同的规则。这是BOUNDED CONTEXT存在的意义。 缓慢演化：结构应该在重构的过程中“涌现”，而不是在项目第一天由架构师“设计”出来。
5. 为你的BOUNDED CONTEXT和大型结构取一个好名字，并将其纳入UBIQUITOUS LANGUAGE 🗣️
原则：名字就是力量。一个糟糕的、技术性的名字（如“模块”、“子系统”）无法传递领域知识。一个好的名字能揭示其在领域中的角色和意图。 行动： 命名与领域挂钩：不要用“Common Module”或“Shared Service”。用“Inventory Context”、“Trade Execution Context”、“Risk Assessment Layer”。 建立术语表：在团队的Wiki或文档中，为每一个BOUNDED CONTEXT和大型结构建立一个条目，描述它们的职责、边界和与其它结构的关系。 日常使用：在例会、讨论、代码评审和走查时，强迫团队使用这些名字。如果发现人们开始使用不同的名字或模糊的描述，这通常意味着结构已经过时了，需要重新审视。
