type
status
date
slug
summary
tags
category
icon
password
Sub-item
Last edited time
Dec 18, 2024 09:29 AM
Parent item
领域
几年前，我在一家 SaaS 公司工作，该公司可能遇到了所有可能的软件开发问题。代码非常复杂，添加简单的更改可能需要几个月的时间。项目的所有任务和范围均由项目经理单独定义。开发人员不明白他们要解决什么问题。如果不了解客户的期望，许多实现的功能都是无用的。开发团队也无法提出更好的解决方案。
尽管我们有微服务，但引入一项更改通常需要对大多数服务进行更改。该架构耦合如此紧密，以至于我们无法独立部署这些“微服务”。业务人员不明白为什么添加“一个按钮”可能需要两个月的时间。最终，利益相关者不再信任开发团队。我们都很沮丧。但情况并非毫无希望。
我很幸运能够对领域驱动设计有所了解。那时我还远远不是那个领域的专家。但我的知识足够扎实，可以帮助公司最大限度地减少甚至消除所提到的大部分问题。
一段时间过去了，这些问题在其他公司并没有消失。即使这些问题的解决方案存在并且不是神秘的知识。人们似乎并没有意识到这一点。也许是因为 GRASP (1997)、SOLID (2000) 或 DDD（领域驱动设计）(2003) 等旧技术经常被遗忘或被认为已经过时？这让我想起了历史上黑暗时代发生的情况，当时古老的知识被遗忘了。同样，我们可以使用旧的想法。它们仍然有效并且可以解决当今的问题，但它们经常被忽视。这就像我们生活在软件的黑暗时代。
另一个相似之处是关注错误的事情。在历史上的黑暗时代，宗教压制了科学。在软件黑暗时代，基础设施正在淘汰重要的软件设计技术。我并不是说宗教不重要。精神生活非常重要，但如果你正遭受饥饿和疾病的折磨，那就不那么重要了。基础设施也是如此。如果您的软件设计很糟糕，那么拥有出色的 Kubernetes 集群和最精美的微服务基础设施对您也无济于事。
软件黑暗时代是一个系统问题
软件黑暗时代是一个非常强大的自我延续系统。如果不了解大局，就无法解决系统性问题。系统思维是一种有助于分析此类复杂问题的技术。我使用这种技术来可视化软件黑暗时代。
你可以看到事物相互加速的一个大循环。如果不干预，问题就会变得越来越大。领域驱动设计如何解决这个问题？
与大多数著名的编程大师不同，我们不希望您只相信我们的故事。我们可以弥补一下。幸运的是，我们可以用科学来解释它为什么有效。更准确地说，是基于科学研究的优秀《加速：精益软件科学和 DevOps（Accelerate: The Science of Lean Software and DevOps）》一书。书中描述的研究提到了表现最好和最差团队的特征。最关键的因素之一是松散耦合的架构。
如果您认为微服务可以为您提供松散耦合的架构，那您就大错特错了。我多次见过比单体架构耦合程度更高的微服务。这就是为什么我们需要的不仅仅是基础设施解决方案。这就是领域驱动设计（DDD）发挥作用的时候了。
这一关键的架构属性使团队能够轻松测试和部署单个组件或服务，即使组织及其运营的系统数量不断增长，也就是说，它允许组织随着规模的扩大而提高生产力。
(...) 如果忽略这些特征，那么采用部署在容器上的最新的精妙微服务架构并不能保证更高的性能。
(…) 支持此策略的架构方法包括使用有界上下文和 API 作为将大型域解耦为更小、更松散耦合的单元的方法，以及使用测试替身和虚拟化作为隔离测试服务或组件的方法。
()
DDD 不起作用
也许您知道有人尝试过 DDD，但它对他们不起作用？也许你和一个不太理解它的人一起工作，试图强行使用这些技术，并使一切变得太复杂？
也许你在 Twitter 上看到过一些著名的软件工程师说 DDD 不起作用？也许对你来说，这是一个传说中的圣杯，有人声称为他们工作——但还没人见过它。
我们不要忘记，我们生活在软件的黑暗时代。上一个时代的想法有一个问题——有些人可能会错过 DDD 的最初点。在 2003 年首次提出 DDD 的背景下，这并不奇怪。
进入 DDD 世界并不容易。许多书籍和文章由于过度简化而忽略了最重要的 DDD 要点。它们也经常用脱离现实的抽象例子来解释。太长、太复杂、难以理解的例子也并不罕见。让我尝试用最简单的方式解释 DDD。
从黑暗时代到文艺复兴
DDD 技术可以分为两个部分。战术和战略模式。战术领域驱动设计模式是关于如何在代码中实现解决方案。战术 DDD 中没有复杂的技术——它完全是关于面向对象编程的良好实践。但在编写代码之前，您需要知道要实现什么。这就是战略 DDD 模式发挥作用的地方。
许多描述 DDD 的资料来源大部分时间都在讨论战术模式。有时，他们甚至会跳过战略模式。您可以仅使用战略模式来练习 DDD。在某些项目中，使用战术 DDD 模式甚至是大材小用。不幸的是，大多数人正在做完全相反的事情。他们只使用战术模式，而不使用战略部分。这太可怕了。
如果有人问我产品软件工程中是否存在灵丹妙药(银弹)，我只会说一个候选者：领域驱动设计战略模式。战略 DDD 帮助我们得到以下问题的答案：
- 您正在解决什么问题？
- 您的解决方案能否满足利益相关者和用户的期望？
- 该项目有多复杂？
- 哪些功能不是必需的？
- 如何分离服务以支持长期快速发展？在实施新项目、添加新功能或进行重构时
这些问题至关重要。战略 DDD 模式为我们提供了一种一致且可预测地回答这些问题的方法。一些工程师告诉我他们“只是工程师”。他们不太关心谁使用他们的软件或为什么使用他们的软件。例如，他们只是实现 JIRA 任务——构建在输入上有一些字节、在输出上有一些字节的服务。这种心态会导致工程师和客户之间的巨大脱节，而我们作为工程师正在努力解决客户的问题。如果没有适当的沟通，就很难创建以正确的方式帮助客户的解决方案。这就是最终的目标——不仅仅是处理字节。
在项目的规划阶段花费少量时间是很诱人的。尽快开始编码并尽早完成。当有人有这样的疑问时，我想说“用 5 天的编码时间，可以节省 1 天的计划时间”。未提出的问题不会神奇地消失。
克服软件黑暗时代的最佳方法是从多个角度对其进行攻击。让我们看看 DDD 模式如何攻击系统。
事件风暴
事件风暴是战略 DDD 模式和一般软件开发的游戏规则改变者。我无法相信为什么它还没有被世界上的每个团队采用。事件风暴是一个研讨会，在此期间有问题的人（通常是开发人员）与有答案的人（通常是利益相关者）会面。在会议期间，他们可以快速探索复杂的业务领域。一开始，您专注于构建基于领域事件（橙色便签）的完整工作流程。事件风暴是一种超级灵活的方法。因此，您可以验证您的解决方案是否满足预期要求。您还可以根据会话的目标探索数据流、潜在问题或用户体验。
验证解决方案是否没有缺陷以及是否符合用户的要求需要几分钟的时间。在开发和部署的代码中引入更改和验证想法的成本要高得多。但是更换黑板上的便利贴成本非常低。
土木工程师或火箭工程师可以很快看到错误的结果。他们在完成构建过程之前就可以看到明显存在问题。对于软件来说就不那么简单了，因为它不容易被看到。我们的大多数关键决定不会伤害任何人。功能开发和维护的问题不会一天出现。
当您计划一个大项目或只是一个故事时，事件风暴很有效。这只是您愿意花多少时间的问题。当我们将它用于一个故事时，它可能会持续 10 分钟到几个小时。我们倾向于花费一天到几天的时间来获得更大的功能。课程结束后，您应该得到以下问题的正确答案：
- 您试图解决什么问题 – 而不是猜测什么可能对最终用户有用或假设“我们更了解一切”
- 利益相关者是否对提议的解决方案感到满意 – 而不是半年后验证这一点实施过程中
- 问题的复杂性显而易见 – 清楚地说明了为什么添加一个按钮可能需要大量工作
- 如何按职责拆分微服务的初步想法 – 而不是盲目地将“类似事物”分组
最终，您将获得利益相关者更多的信任，因为您正在共同规划解决方案。这是比在地下室进行隔离编码更好的方法。事件风暴的优点在于，正确完成的会话的结果可以直接映射到代码。它应该可以帮助您在开发过程中避免许多讨论并大大加快您的工作速度。
你必须从一个明确的目标开始。一个项目的时间过得很快，不知不觉中，你在一个项目上花了半年时间，却发现它对任何人都没有用。你有过这样的经历吗？这种情况发生的频率比您想象的要高，这就是为什么有些人对“工程师”失去信任，以及我们最终成为没有任何自主权的开发人员的原因。
人们普遍担心我们需要“损失”多少时间来进行会话。考虑会话过程中损失的时间并不是正确的方法。相反，您应该考虑如果不进行该会话您将失去的好处。我在运行一次事件风暴会议时听到了这个故事，导致该项目的实施停止了几个月。这听起来可能很糟糕，但在会议期间，团队发现当前的假设完全无效。该项目的继续将导致彻底失败。即使该会议在短期内看起来很耗时，该公司也避免了几个月无用的开发。
事件建模
2018 年，Adam Dymitruk 提出了事件建模技术。该想法在很大程度上基于事件风暴技术，但添加了一些新功能。它还特别强调了会议的用户体验部分。一般来说，这些技术非常兼容。即使您继续使用事件风暴，您也可能会从事件建模中找到一些可以使用的有价值的方法。您可以在 eventmodeling.org 上阅读有关该技术的更多信息。
界限上下文和事务边界（聚合）
有界上下文是另一种战略 DDD 模式，可以帮助我们将大模型分割成更小的逻辑部分。
这是实现适当的服务分离的关键。如果您需要接触系统的一半来实现和测试新功能，那么您的分离是错误的。
除了错误的分离之外，还有缺乏分离。通常，缺乏分离的症状是神物体（知道太多或做太多的巨大物体）。在这种情况下，更改将主要影响一项服务。这种方法的成本是更大的系统故障风险和更高的变更复杂性。
换句话说，在这两种情况下，开发项目都会变得更加困难。
帮助发现界限上下文和聚合的一个很棒的工具当然是事件风暴。会议的结果是，您可以直观地了解应如何在服务和接触点之间划分服务和接触点。
通用语言
通用语言是一种战略 DDD 模式，涵盖在开发人员、运营、利益相关者和用户之间建立通用语言。这是最被低估的战略 DDD 模式。因为谁关心语言，对吧？
我花了一些时间才发现开发人员和非开发人员之间有多少沟通问题是因为使用不同的语言而造成的。这是多么痛苦啊。我鼓励你也关注这一点。由于沟通不畅，开发人员无法解决正确的问题，因为没有人了解对他们的期望。
如果我告诉您事件风暴将帮助您开发通用语言，您会感到惊讶吗？与利益相关者一起举办会议迫使您与他们交谈。当你们无法互相理解时，就很难共同制定解决方案。这就是为什么不要错过研讨会上的利益相关者至关重要！
DDD 能解决所有问题吗？
即使 DDD 很棒，它也不能解决我们遇到的所有问题。管理你的期望很重要。即使我们在我的团队中高水平地使用这些技术，我们仍然怀疑创建的设计是否足够好。有时我们不知道如何解决问题。有时我们会从代码回到设计阶段。有时我们会做出错误的决定。所有这些都是非常好的情况。世界上没有一支球队不存在这些问题。最好假设它会发生并且不要感到惊讶。但我们知道，如果没有 DDD，这些问题将会更加严重。
在使用 DDD 时，您应该特别注意避免：
- 预先进行大设计
- 实现“面向未来”的代码
- 尝试创建完美的东西
相反，您应该：
- 专注于以一种快速的方式将 MVP 交付给用户时间很短（我的意思是1个月而不是6个月）
- 如果你需要“为了未来”实现一些东西，因为以后添加它会更困难，这是一个非常糟糕的迹象。您应该考虑如何方便以后添加它
- 即使你尽了最大努力，你的设计也不会从一开始就完美——随着时间的推移改进它会更好。
对于一些团队来说，可能需要做很多工作才能达到这个水平。但根据我的经验，我可以向你保证这是可能的。再次交付软件所带来的乐趣是值得的！
注意
如果您认为自己应该成为技术领导者来提出此类改进建议，那您就错了！早期，当我还不是领导者时，我已经向我工作的团队提出了许多改进建议。你需要与你的队友进行良好的争论。
我们总是在章节中解释这些技术“为什么”有效。当你使用这些论点时，它们应该足以说服他们。如果因为你的团队思想封闭而行不通，那么这就是考虑换工作的充分理由。
软件复兴
很难在一章内深入介绍所介绍的技术。我的目标是激励你质疑现状。这不是我们的行业应该如何运作的。如果您对现状不满意，我希望我能激励您学习新技术。这是对抗软件黑暗时代的最佳方式。
战略 DDD 模式怎么样？本章实际上是对我们的章节系列的下一部分的介绍。在接下来的几个月中，我们将在一个完整的示例项目中深入介绍最重要的战略 DDD 模式。
在软件黑暗时代，你是谁？
只是一个盲目遵守别人强加的规则的普通乡巴佬？
宗教裁判所，谁会试图去憎恨和扼杀任何不寻常的做法？
炼金术士，想炼金子？
即使没有科学依据？或者也许您正在地窖里偷偷地阅读禁书？
也许您正在寻求与我们一起结束软件黑暗时代并开始软件复兴？