领域驱动设计中有一个重要方面很少被提及。我认为这是 DDD 最重要的方面，但是如果您在网上搜索“领域驱动设计”，您不会找到它。
这件宝藏一直隐藏在人们的视线中。这是 Eric Evans 的 DDD 书第 8 章中的 Share Pie 故事。(Share Pie是一种投资组合份额策略，类似一个馅饼或饼图，具体组成由百分比份额构成)
对我来说，这个故事就是 DDD 的真正意义所在：培养建模者的设计思维，以推动产品创新并实现价值的持续交付，涉及与领域专家的频繁合作。
这也是一个很棒的故事，我从不厌倦重读，并提醒我为什么喜欢 DDD。
案例起因
在DDD一书第 8 章“突破”中，您很快就会感觉到埃里克正在为史诗般的事情做准备。任何以“经过漫长的纽约重构冬天”开头的故事都一定会让 DDD 爱好者兴奋不已：
经过纽约漫长的重构冬天，我们得到了一个模型，该模型捕获了该领域的一些关键知识，并为应用程序做了一些实际工作的设计。我们正在开发一个大型应用程序的核心部分，用于管理一家投资银行的银团贷款。
这听起来像是一个挑战，但尽管如此，他还是对他们冬季工作的结果感到满意。然后他通过告诉我们机会的规模（以及一点点名声）来引起我们的注意：
当英特尔想要建造一座价值 10 亿美元的工厂时，他们需要一笔巨额的贷款（需要融资），任何一家贷款公司都无法承担，因此贷款人组成了一个财团，集中其资源来支持一项设施。投资银行通常充当辛迪加领导者，协调交易和其他服务。我们的项目是构建软件来跟踪和支持整个过程。
遭遇问题
然后我们确切地了解到他在纽约漫长的重构冬天意味着什么——收拾别人的烂摊子。但至少现在他们处于一个很好的位置。
我们感觉很好。四个月前，我们遇到了一个完全不可行的、继承的代码库的大麻烦，此后我们一直在努力实现一个连贯的模型驱动设计。
但随后故事发生了转折。毕竟他们不是在这么好的地方。他们处于我们在某个时刻都发现自己所处的艰难境地：八二法则。80%实现快乐路径相对容易，实现20%的其他要求则带来了更加复杂的挑战。
但也有一些令人不安的迹象。我们不断遇到使设计复杂化的意外需求。一个主要的例子是人们逐渐认识到，融资Facility中的份额只是一个指导方针……
Eric 和他的团队知道代码的日益复杂将成为一个关键问题。更重要的是，作为熟练的建模者，他们能够感觉到他们对该领域的概念性理解可能存在缺陷。
我们开始怀疑我们的困难是基本设计问题的征兆。
融资和贷款两个概念傻傻分不清楚
然后故事发生了积极的转折。Eric 和他的团队在他们的理解和模型中找出了根本问题。
突然一个星期，我们意识到出了什么问题。我们的模型以一种不适合业务的方式将 Facility融资 和 Loan贷款 份额联系在一起。
他们在白板上与领域专家合作设计他们的新模型，并通过具体场景来验证模型。
在业务专家点头、热情帮助的情况下……我们在白板上计算出一个新模型……我们使用新模型的可视化处理了许多场景
我知道 Eric 是现实生活中具体用例的忠实粉丝。他喜欢证明他的模型在现实中确实有效。在 Share Pie 故事中，他通过分享一个具体示例向我们展示了这一点（以下只是完整示例的一小部分）：
该图表显示，借款人已选择从融资项下承诺的100万美元中提取最初的50万美元。这三家出借机构按照融资份额的确切比例分摊其份额，从而在出借机构之间分配了50万美元的贷款…
再次展示他们的建模专业知识，Eric 和他的团队能够准确地思考为什么旧模型不起作用以及产生更好模型的关键是什么。他们偶然发现了共享的领域概念。
我们有两个深刻的见解。首先是意识到我们的“融资”和“贷款”中，是有通用概念和基本概念的区别：份额、融资份额，贷款份额、付款份额。
这种新见解确实转化为积极的建模突破。他们的基本设计问题已得到强调。
突然间，在这种看待领域的新方式的基础上，我们可以相对轻松地完成我们遇到的每一个场景，比以往任何时候都更简单。
重构不是银弹
但随后故事发生了下滑。
我们的新模型运行良好。真的，真的很好。
我们都觉得恶心！
我们面临着严峻的最后期限；该项目已经危险地落后于计划。
这个老问题让 Eric 和他的团队在不需要的时候拜访了他们：有一个项目截止日期。更糟糕的是，他们没有能力迭代新模型。需要大修（注意：不是通常意义上代码重构，二是领域模型重构，模型重构其实意味着大部分重写，banq认为这里只是为了维护refactoring这个词语的面子，其实就是重写！）：
重构的福音是你总是小步走，总是保持一切正常。但是将我们的代码重构为这个新模型需要更改大量支持代码，并且中间几乎没有稳定的停止点。
Eric 和他的团队与他们的项目经理会面。Eric 解释说，模型·重构会增加短期风险，但会降低长期风险。项目经理同意保护 Eric 和团队，从而英勇地成为故事中的好人。
他同意了我们，并告诉我们他会处理高温。我一直非常钦佩他做出这个决定所需要的勇气和信任。
随着故事接近尾声，故事继续回到积极的轨道上。Eric 和他的团队的勇敢决定现在对业务层面产生了重大影响。他们开发的share pie（份额饼图）概念已成为核心产品概念，甚至被营销团队与客户使用。
这个 Share Pie 成为整个应用程序的统一主题。技术人员和业务专家用它来讨论系统。营销人员用它来向潜在客户解释这些功能。
在本章的结束讨论中，Eric 强调了模型突破的另一个重要价值——它们为更多的建模突破奠定了基础。
在软件的 Share Pie 版本发布几周后，我们注意到该模型的另一个尴尬方面使设计复杂化
Eric 然后通过随意地提醒我们为什么这个故事和 DDD 的含义对每个软件专业人士都很重要来结束本章。
我们的开放步伐正试图加快，而此时大多数项目正开始陷入已建成项目的大规模和复杂性之中。
分析share pie故事
我喜欢 Share Pie 的故事，我发现我们可以从中学到多少关于设计、建模和 DDD 的重要课程，这很有趣。我希望你也喜欢我的亮点，但我仍然建议阅读书中的整个故事。
- 现代产品主导型组织
这个故事已有 20 年的历史，但仍然为今天的优秀产品团队设定了标准。软件工程师不是将需求翻译成软件的打字员。软件工程师致力于设计他们正在构建的产品和功能。
Eric 和他的开发团队与他们的领域专家合作发明了 Share Pie 的概念，该概念成为重要的产品和营销功能。
（banq：这说明程序员已经介入了产品经理的职责范围：以产品设计思维解决问题的好处 ）
- 领域设计师
Share Pie 是一个新的领域概念。Eric 和他的团队不仅仅是模拟物理世界中已经存在的东西。他们正在设计和发展领域的各个部分。
这可能是 DDD 中最容易被误解的部分之一。DDD 是关于设计领域以及对其现有部分进行建模。创新是发明新思想、新领域概念和新领域术语。
（banq注：领域设计不是被动的分析需求，承接演绎需求，而是对需求进行干预，这里涉及到问题空间和解决方案空间，DDD不只是属于解决方案空间，而会涉及道问题空间重新看待的问题：DDD中问题空间和解决方案空间是一个伪命题）
- 超越幸福之路
8/2规则在这个故事中很明显。Eric 和他的团队已经构建了一个适合所有常见用例的初始模型，但真正的艰苦工作开始尝试实现所有其他用例。
作为一名工程师，如果一个模型看起来很简单，请始终提醒自己在它使您眼花缭乱之前继续寻找任何隐藏的复杂性。
(banq:这类似机器学习的算法模型和数据样本之间的关系，在测试样本下你的模型是正确的，但是到了生产数据样本上，算法模型准确率大幅度下降，问题还是出在你的算法模型只覆盖了八二法则中的八，那20%你没有考虑到)
- 在复杂性变得松散之前退后一步
当 Eric 的团队看到代码变得越来越复杂时，他们将每个新功能融入原始模型中，他们必须做出一个重大决定：继续修改内容还是退后一步并尝试重新设计模型？（banq：继续小修小补属于重构refactor，而重新设计核心业务模型，等于代码重写！）
这可能是阻止代码库在接下来的 10 年中成为无法维护的混乱的决定。
在代码库中工作时，我们都会面临这些决定。如果我们在复杂性失控之前投资我们的模型，我们可以保持我们的代码健康且更易于使用。但是我们需要建模和设计技能来做到这一点。
- 使用具体绑定的上下文场景验证模型
当人们说 DDD 是学术和纯粹主义者时，我知道他们还没有接触过真正的 DDD。如果您遇到过 Eric，您会很快了解到他致力于为具体场景建模，而不仅仅是使用抽象模型。
在 Share Pie 故事中，Eric 的团队在白板上与领域专家一起绘制具体用例以验证他们的新模型。如果你读过这本书，你会发现这个场景非常详细，插入了实数和事件序列，使其尽可能真实。
- 为乐趣和利润建模
这个故事中的所有成功事件都围绕着模型的变化，这些变化要么直接带来业务收益，例如share pie，要么间接地加快添加新功能的速度。
虽然 Eric 确实喜欢建模并从中获得乐趣（并且也承受着很大的压力），但他的乐趣来自于制作对业务有用的东西，而不是创建可以向学术朋友炫耀的漂亮模型。
- 连续建模
在这个故事中没有特别强调的主题之一是建模的不变性（持续一致性）。如果您不是每周都在自己的领域中发明像 Share Pie 这样的概念，请不要感到羞耻，因为这些突破发生的频率要低得多。
使 Share Pie 取得重大突破的是团队每天进行的许多小模型重构。这些与领域相关的小改动（如重命名和提取部分代码）的成本非常小，应该成为每个专业开发人员的好习惯。
（banq:这是持续一致做一件事带来的复利涌现，滴水穿石，100个大道至简的真相）
- 模型符合现实
没有一个糟糕的截止日期，没有一个关于软件开发的故事是完整的，这个截止日期会使整个项目处于危险之中并让每个人都感到压力（尽管我们真的不应该美化这一点）。
在这个故事中，工程师和项目经理决定大胆地花时间改进模型，冒着错过最后期限的风险。这肯定需要很大的勇气，但这不是为了更好的模型吹嘘自己的权利，而是为了降低项目的长期风险。
有时，即使功能延迟，我们也需要大胆投资于模型。在其他情况下，我们需要接受我们的模型是混乱的，但改进它的努力是不合理的。
DDD 并不是优先考虑建模而不考虑交付的借口，而是挑战那种以牺牲长期可持续性为代价过度关注短期的借口。（DDD是克服短视的）
- 战术模式是额外的，而不是主要角色
Share Pie 故事中很少提及实体、聚合和值对象。简要提及它们是为了更清楚地解释 Share Pie 模型。
这是对 DDD 本身的一个很好的反思。战术模式在创建和描述模型时很有用，但它们不应成为关注的中心。在教授 DDD 时，我们应该尽量避免在不教授建模价值的情况下教授战术模式。
让战略设计成为DDD建模的十年：一个精心设计和进化的领域模型可以从产品创新和更易于理解和更改的代码中提供许多好处。我的愿望是，下一个十年的软件开发将重新发现设计的价值，而 DDD 社区将更加强调真实建模和建模突破。