首先了解您的领域：每个公司都有自己的业务领域（有时有几个，有时几十个，有时数百个），在其中运营和赚钱。
如果你不能很好地理解这个领域，从长远来看你很可能会失败。在任何项目开始时——当我们的知识非常有限时——我们必须做出很多不同的决定。然后，随着时间的推移，我们的知识会增长，决策的数量会减少。
由于缺乏知识以及我们面临许多决策，我们可以预见其中许多决策都是错误的。
问题是为什么不在开始时花更多的时间来理解我们想要构建什么以及为什么想要构建一些东西，并提高我们最初决策的质量？最终，我们将在我们周围创造更安全的环境，并且很可能避免如果我们跳过最初的步骤就会出现的许多问题。
举办研讨会
理想情况下，开场（第一次研讨会）将有决策者（有权做出此类决定的人）和领域专家（对流程的不同部分有很多了解的人）参加，如物流师、会计师、销售、律师等（如果有现有的遗留系统，这些人可能是与该系统合作最多的软件开发人员，因为他们通常对业务有很多了解）。
当一切都确定之后：
- 参与者--我希望不要超过 8 人，因为我无法将全部精力放在每个人身上。
- 地点--现场或远程--我更倾向于现场，因为我可以与参与者有更多的互动，人们也会更活跃（根据我的经验）
- 时间--研讨会需要多少时间？对于第一次研讨会，我通常计划 3 次 1.5 小时 * 2 天。如果我发现我们需要更多时间（这种情况经常发生），我就会计划后续活动
你可以开始考虑你要使用的方法和技巧。有许多不同的方法：
以及上述方法的许多其他替代方法或组合。我通常会选择前两种方法中的一种--事件风暴法和领域故事法--并根据偏好交替使用。
一、领域定义
每次我们构建软件时，我们都会在一个称为域的区域中进行操作。它描述了我们的业务。有可能：
- 电子商务——该领域可以包括在线购物、产品目录、订单处理、支付和许多其他较小的部分
- 税收——在这个领域我们可以找到所得税、公司税、税收合规或税收政策等领域
- 医疗保健——这可以包括患者管理、预约安排、医疗记录、处方管理等领域。
- 教育——作业跟踪、学习平台、学生注册、评分等领域。
- 物流——仓储、运输、库存管理、路线优化或交货安排等
我们希望构建一个可供任何健身工作室使用的 SaaS 应用程序。它将涵盖您能想到的一切，从最初的报价到饮食计划。
- 我们希望准备优惠并将其推广给我们的潜在和现有客户。如果有人有兴趣加入或续订会员资格，则应签署合同。
- 合同签订后，客户将获得进入工作室的通行证。
- 当然，当现有通行证到期时，我们需要能够为客户提供新合同。
- 它还需要能够生成一些报告，一开始可能只是销售的一些通行证。
语言分析分解：
1、我们希望构建一个可供 任何健身工作室使用的SaaS 应用程序。它将涵盖您能想到的一切，从最初的报价到饮食计划。
从这次对话中您可以学到的第一件重要的事情是您需要为健身工作室构建 SaaS 应用程序。这是一个技术性的东西，但它也展示了一种商业模式（你想如何从中赚钱）。写下来，您需要在业务分析研讨会之后与您的公司讨论这个问题。为什么？通常，出现的想法可能不是业务的最佳解决方案，如果您认为有更好的做事方法，您就可以开始讨论。
2、我们希望准备优惠并将其推广给我们的潜在和现有客户。如果有人有兴趣加入或续订会员资格，则应签署合同。
太好了，我们有了初步的要求，我们将在研讨会上更详细地讨论这些要求。有人将准备优惠并向新客户和现有客户进行广告。如果一个人决定接受，就会签订合同。这为您提供了一个框架，以便您可以计划您的研讨会并定义您将关注的目标。
正如您可能看到的，此时可能会出现不同的问题：
- 我们的申请中会充分准备好offer吗？
- 它将如何推广？通讯？在应用程序内？
- 如果此人有兴趣但想要折扣怎么办？
- 合同是在应用程序内签订的还是直接在健身室签订的？
这些问题应该在您与领域专家和决策者的会议中得到回答。但很高兴我们已经拥有它们。把它们写下来，这样你以后就不会忘记提及它们。
3、合同签订后，客户将获得进入工作室的通行证。
回头一看，已经有4个业务流程了，下一个才刚刚出现：
- 提供准备
- 优惠促销
- 合同准备
- 合同签订
- 通行证登记
4、最后一步——通行证注册——是签署合同的结果，并触发客户收到通行证。
您可能首先想到的问题是：
- 通行证如何交给顾客？
- 是否只有一种方法或多种方法，例如现场、通过电子邮件或邮寄？
等等。同样，这些都是值得关注的问题，应该在未来的讨论中予以注意和使用。
我们已经分析了几乎整个声明。缺少 2 个零碎问题：
（1）当然，当现有通行证到期时，我们需要能够为客户提供新的合同。
这是它的工作原理！当现有通行证到期时，我们会向客户发送新的合同报价。可能会问以下问题：
- 通行证过期意味着什么？
- 我们应该在通行证到期之前准备报价吗？
- 折扣是否应该包含在合同报价中？
- 是否存在应自动续签合同的情况？
看看我们从如此简短的声明中提取了多少有关核心业务流程的信息！这只是开始，因为这些只是你的想法。你可以想象头脑风暴会议中会发生什么。
声明的最后一部分与客户没有直接关系，但它可以帮助健身工作室比较每个月的销售额，并准备一些在未来几个月或一年要实现的目标：
（2）它还需要能够生成一些报告，一开始可能只是出售一些通行证。
我们希望能够生成有关已售通行证总数的报告。好吧，我们需要关注另一个领域。目前，我们可以假设已经与可能使用我们的应用程序的健身工作室协商了生成哪种报告的决定。如果没有，您在研讨会期间有一个完美的问题要问：“为什么选择这份特定报告而不是其他报告作为 MVP？“
恭喜！现在我建议您稍微整理一下上述信息，并为研讨会做好准备。
二、子域草案
完成前面的所有步骤后，我们准备继续我们的旅程，并尝试准备将Fitness Studio 域拆分为多个子域的初稿。但还有很长的路要走。
首先，让我们尝试定义什么是子域。
每个企业都在某个业务领域运营——我们都知道这一点。为了保持效率，通常分为不同的区域，如仓储、交货、会计等。此外，每个业务单位或（在大公司中）部门内都有许多不同的流程。通过这些流程，企业可以为客户提供服务并产生收入。
医疗保健系统：可以包括患者管理、日程安排、医疗记录、处方管理等领域。我们假设每个领域都可以被视为子域。
患者管理和日程安排可以属于同一部门吗？是的，他们当然可以！患者管理的一部分可以属于多个科室吗？是的，它可以。这就是为什么说子域等于部门是错误的，并且会在将来给你带来很多问题。
让我们考虑另一个实际例子来进一步说明域驱动设计中子域的概念。
想象一下您正在构建一个在线市场，类似于亚马逊。在这个市场中，有几个不同的功能领域，每个领域都有特定的用途：
- 产品目录子域：
- 该子域管理与产品相关的所有内容：添加新产品、更新产品信息以及将产品分类为不同部分（例如电子产品、服装、书籍）
- 订单管理子域处理与客户订单相关的活动：下订单、跟踪订单等。
- 在这里，用户可以对他们购买的产品留下评论和评级，帮助其他人做出明智的决定
这些区域中的每一个都代表在线市场应用程序上下文中的一个子域。通过定义这些子域，开发人员可以专注于每个区域内的特定复杂性和规则，而不会被整个系统淹没。这种方法允许团队成员之间进行更清晰的沟通，并确保应用程序的每个部分都得到有效的开发和维护。
还有一件非常重要的事情需要记住。有时，一个子域可以代表另一个域并包含许多其他子域 - 这可能发生在大公司中。因此，当您对域进行建模并运行研讨会并对其进行分解时，您可能会发现一个或多个子域太大而无法适应一个系统，而您需要另一个系统。
如何找到子域呢？
这就是建模技术的用武之地。建模技术有很多——有些较旧，有些很新。我最喜欢的两个是：
但您也可以使用其他技术，例如故事映射、影响映射、故事风暴或其他任何技术。
官方将事件风暴分为3个级别：
- 大局观
- 过程
- 设计
但我爱上了Radek Maziarka 提出的另一个层次——有界上下文。在本系列中，我们将重点关注其中的 3 个：
- 大局观
- 过程
- 有界上下文
每个都将是不同重点领域的一部分。当我们谈论创建子域时，我们需要从大局开始。
您如何组织这样的头脑风暴研讨会？我通常会尝试邀请决策者和领域专家。有时这些人是业务人员，有时是开发人员（在遗留系统中，他们通常最了解业务流程），或者两者兼而有之。我更喜欢少于 10 人的会议（包括我作为主持人）。
现场还是远程？两者皆有可能。
- 如果您去现场，您将需要橙色卡片（而不是粘性卡片，而是静态卡片 - 您可以轻松移动它们）、标记和用于粘贴卡片的长墙。
- 如果您决定远程运行研讨会，您可以使用 Miro 等软件（在我看来，远程事件风暴会议没有更好的选择）。
尝试将研讨会分成几个部分 - 我们通常决定在研讨会的每个小时后进行短暂的休息。
我们通常使用两种类型的笔记。活动事件：
这是代表我们域中可能发生的所有业务事件的主要类型。经验法则是用过去时（发生的事情）来命名它，因为它是已经发生的事件。
另一个是热点Hotspot：
这些是研讨会期间无法回答的问题和意见（对此没有任何了解）或我们想要转移的问题和意见。
现在是时候围绕我们的健身工作室领域开始研讨会了。每个参与者都会获得他/她需要的尽可能多的橙色笔记，并开始粘贴商业活动。那时，没有任何时间线的焦点，也没有好的或坏的笔记。一段时间后，你的墙会看起来像这样：
包含两种事件活动：
- 与业务相关的事件，例如合同签订或通行证过期
- 与技术相关的事件，例如发送到 Offer API 的请求 或单击的按钮
删除技术部分，因为它们在业务和子域蒸馏的背景下并不重要。注意：可能存在重复的事件，因此只需丢弃所有重复的事件即可。
清理后，您的白板应如下所示：
对事件活动分组
现在是对各种事件进行分组的时候了。尝试根据以下条件对其进行分组：
- 合并相似的语法措辞，例如Offer with Offer、Pass with Pass 等。注意：小心——这是危险的。有时，在一种情况下提供在另一种情况下可能意味着其他含义
- 时间线——下一个事件活动发生之前必须发生什么
- 参与者——谁负责流程的执行
- 流程结束 – 要执行流程，我们需要几个事件。如果下一个事件不适合该流程，则可能表明它可以是单独子域的一部分
用不同颜色画圈标记：
标记完毕后，我们就准备对其进行分组：
理论上，一切都很好。但我犯了一个错误。在继续阅读之前，请再次查看图表并尝试找到它。其中一个事件与流程不匹配。
我们希望向潜在客户发布优惠。需要几个步骤：
- 必须有人准备它
- 然后必须进行审查和纠正
- 准备好后必须发布
瞧，我们的报价已发布。那么，发送报价询盘（Inquiry sent for an offer）在这里有什么作用呢？这就是错误。
我不小心把它放在其他优惠活动旁边，因为它包含众所周知的词——优惠。但还有另一个事件 - Inquiry ，之前没有出现过，并且此事件是客户（ 另一个参与者）在完全不同的流程中采取行动的结果，而不是准备报价的人（可能是推销员）。让我们修复我们的图表：
现在我们的活动已分组。这是我们的子域草案。它们将来可能会发生变化（例如，在流程级事件风暴期间或当您的域发生变化时），但它是一个可以继续使用的良好支架。现在是时候给它们命名了——记住与研讨会中的每个人一起这样做：
三、子领域的调整
到目前为止，我们已经做了很多出色的工作。我们从大局角度分析了我们的业务领域，记录了事件并创建了子领域的初稿。这很好，但还不足以开始编码。
是时候继续前进并调整我们的子域了。我们如何做到这一点？答案是流程级事件风暴。这项技术使我们能够专注于草稿子域中的具体流程。多亏了它，
让我们最后看一下大局事件风暴研讨会的结果：(上图)
它明确指出我们至少有 5 个子域需要处理。我们将重点关注其中的两个，因为其他人的分析将是一项可重复的工作——多亏了它，你可以尝试自己练习。选择将涵盖：
- 优惠Offers
- 合约Contracts
在开始之前，我想向您介绍我们将使用的 4 种新型卡片：
策略Policy卡
- 颜色：通常为紫色
- 描述：描述决策规则或业务策略，规定在某些情况下应采取什么操作。政策通常源自业务规则或法律要求
- 目的：策略指导域内的决策过程，并且通常会导致根据某些条件生成命令
命令卡
- 颜色：通常为蓝色
- 描述：表示用户或系统所采取的操作，该操作会更改域的状态。通常是动词或动词短语，例如签署合同或取消订阅
- 目的：命令对于理解系统中可以执行哪些操作以及什么触发这些操作至关重要
读取模型Read Model卡
- 颜色：通常为绿色
- 描述：表示用户或系统读取或查看的数据。读取模型是系统在处理事件后公开信息的方式
- 目的：它们有助于了解数据如何呈现给用户以及哪些信息可用于做出决策或执行操作
角色Actor卡
- 颜色：通常为黄色（小号）
- 描述：代表与域交互的人或角色。参与者可以是命令的发起者或信息的接收者
- 目的：参与者帮助识别谁或什么正在与系统交互，提供对用户角色或在域中发挥作用的其他实体的洞察
因此，这组卡片将允许我们显示谁与流程交互、向与之交互的人提供哪些数据、谁触发导致事件的命令等等。在流程级事件风暴研讨会之后，我们的图表将如下所示：
与我们之前的内容相比，有更多的细节，特别是在合同子域中。
在研讨会期间，您会发现一些子域非常简单。没有业务规则，流程很简单。这应该告诉您，它可能是一个非常简单的支持或通用类型的子域。在我们的示例中，优惠将是其中之一的示例。
相反，合同是核心子域的良好候选者- 已经有 3 个策略，基于验证将处理一个或另一个操作。在研讨会期间，我们发现了比大局事件风暴更多的流程。例如，存在以前不存在的客户验证或合同拒绝。
好吧，让我们退一步来定义提到的所有子域类型：
核Core子领域
- 描述：核心子域是您的业务的核心部分，使其与竞争对手区分开来。这是创造主要商业价值的地方，也是客户选择您的产品或服务而不是其他产品或服务的原因
- 特点：该子域对于您的业务来说是独一无二的，需要内部开发以满足特定的业务需求。它很复杂，经常发展，需要不断完善和创新
- 焦点：资源和注意力方面的最高优先级
辅助支持子领域
- 描述：支持子域名是业务所必需的，但不构成其竞争优势。它们支持核心业务，但不是业务的主要焦点
- 特征：这些领域不如核心子领域复杂，仍然需要特定的业务逻辑，但对于产品或服务的独特销售主张并不那么重要
- 重点：通常是内部开发（也可以外包），但与核心相比，重点较少
通用的子领域
- 描述：通用子域是许多企业和行业通用的标准功能。它们不提供竞争优势并且不特定于业务
- 特征：这些通常是标准化流程或功能，具有市场上成熟的解决方案
- 焦点：企业选择现成的解决方案
在决定您的子域可能采取的方向之前，与业务部门讨论他们对该子域发展频率的预测非常重要。您还应该查看历史数据，了解前几年流程发生变化的频率。这将为您提供一种更结构化的方式来查看潜在的变化。我可以推荐使用 DDD Crew 的核心域图表，它允许您记录此类潜在的变化：
从图中您可以看到，报表模块的复杂度较低，业务差异化也较低，因此您很有可能找到可以购买的现成解决方案。另一方面，有些合同具有高度复杂性和高于平均水平的业务差异化。这意味着您可能必须自己构建它们。还有属于支持类型子域的优惠和通行证，但两者都有可能在不久的将来改变其性质：
- 由于可能生效的政策或法规数量增加，优惠可能会变得更加复杂。由于这些将基于您的自定义内部规则，因此从业务角度来看它将更加与众不同（您不会找到现成的解决方案，此外您可能希望将有关它的知识保留在公司内部而不是外包它）
- 今天的通行证并不那么复杂（它们仍然有一些业务规则），它们可以成为您和其他公司可以使用的通用解决方案。不是今天，但几个月后可能会有一个玩家将其作为可集成（现成）解决方案出售
通过这种方式，您可以创建一种地图来记录您的思维方式和构建软件的策略。
我还想提一件事。有时会出现一种情况（尤其是在大公司中），在研讨会期间您会注意到其中一个子域太大。通常这种感觉是正确的，这个子域应该是进一步调查的主题。
好的。现在我们已经对子域进行了微调，我们已经准备好进行战略域驱动设计的最后步骤之一。它被称为有界上下文.
banq注：
活动事件=点；上下文=线，子域=面。
线由点组成，建议从事件活动点开始，从下而上实现涌现发现上下文。
子域的面由很多上下文的线组成。
由下而上设计流程：点->线->面
而不是由上而下设计：面->线->点
因为这是一个探索发现过程，无法从顶层设计开始，由上而下是一种科学还原论方法，认为事物由分子组成，分子由原子组成，只要找到所有原子就能组装成任何一个物体，其实很多物体现象是由原子之间相互作用才有的涌现属性，如果拆分成单个原子反而找不到这些属性，1+1>2，大于2的属性不属于俩个1，而是两个1组合在一起才有的。
事物由下而上涌现产生，如果你颠倒次序，由上而下学习复制，你以为这样的复制还是原来的那个事物吗？上下颠倒制造复制一个就是原来的吗？这是在做模具吗？不是，社会现象不是用机械模具复制出来的。