DDD介绍《领域驱动设计之PHP实现》全书翻译-DDD介绍《领域驱动设计之PHP实现》全书翻译-建筑风格《领域驱动设计之PHP实现》全书翻译-ValueObject《领域驱动设计之PHP实现》整书翻译-实体《领域驱动设计之PHP实现》整书翻译-服务《领域驱动设计之PHP实现》整书翻译-领域事件《领域驱动设计之PHP实现》整书翻译-模块《领域驱动设计之PHP实现》整书翻译-聚合《领域驱动设计之PHP实现》全书翻译-工厂《领域驱动设计之PHP实现》全书翻译-存储《领域驱动设计之PHP实现》全书翻译-应用服务《领域驱动设计之PHP实现》全书翻译-整合语境，您可能熟悉我们正在谈论的内容，因为我们大量借鉴了他们的定义和解释。领域驱动设计(DDD)是一种帮助我们理解和建模软件设计的方法。它提供了战略和战术建模工具来帮助我们设计高质量的软件来实现我们的业务目标。本书的主要目标是向您展示领域驱动设计战略模式的PHP代码示例。如果您想更多地了解策略模式和DDD的核心，您最好阅读VaughnVernon的《领域驱动设计精简版》和EricEvans的《领域驱动设计参考：定义和模式摘要》。更重要的是，领域驱动设计与技术无关。相反，它是围绕业务挖掘知识，使用技术来提供业务价值。只有当你有能力了解你公司的业务时，你才有可能参与到软件模型的探索过程中，从而获得一种通用语言（UbiquitousLanguage）。为什么领域驱动设计很重要软件不仅仅是代码。如果您考虑一下，代码绝不是我们追求的最终目标。代码无非是解决业务问题的一种手段。领域驱动设计强调确保业务和软件使用同一种语言。那么为什么你必须用不同的语言来讲述呢？只要打破壁垒，不需要翻译或繁琐的同步过程，信息就不会丢失。每个人都可以为探索业务领域做出贡献，而不仅仅是程序员。由此产生的软件是通用语言的真实体现。领域驱动设计为战略和战术设计提供了一个框架——战略设计确定了业务最重要的领域，并根据业务价值开发它们；战术设计通过经过验证的构建块和模式构建可行的领域模型。领域驱动设计的三大核心领域驱动设计是一种交付软件的方法，主要集中了三个核心点：1.通用语言为了建立业务领域的通用语言，领域专家和软件开发人员需要通力合作.我们和他们没有区别，只有我们。开发软件是一项商业投资，而不仅仅是一项费用。建立共同语言的努力将有助于所有团队成员对领域有更深入的了解。2.战略设计领域驱动设计指定了业务方向背后的战略，而不仅仅是技术方面。这有助于定义内部关系和早期预警反馈系统。在技??术方面，战略设计通过为如何实现面向服务的体系结构提供动力来保护每个业务服务。3.战术设计领域驱动设计提供了持续交付软件的工具和构建块。战术设计工具产生的软件不仅正确，而且易于测试，不易出错。通用语言通用语言和第12章集成限界上下文是领域驱动设计中最强大的部分。就上下文而言，现在假设有界上下文是系统内的概念边界。边界内的通用语言有其特殊的含义，而边界外的语境概念可能有不同的含义。那么，如何寻找、发现和捕捉这些非常特殊的语言。这里有几个要点：确定业务流程、输入和输出的关键点创建一些词汇表和定义使用一些文档来捕获重要的软件概念和其他团队人们共享和扩展上述知识（开发人员和领域专家）。自领域驱动设计诞生以来，新技术不断涌现，以改进构建通用语言的过程。其中最重要，也是当今最常用的是事件风暴。事件风暴AlbertoBrandolini在一篇博文中介绍了事件风暴及其好处，他的解释比我们更简洁。事件风暴，一种用于快速发现复杂业务领域的研讨会形式：它非常强大：它允许自己和许多参与者在数小时而不是数周内提出完整业务流程的综合模型。这很吸引人：整个想法是把有问题的人和知道答案的人聚集在同一个房间里，以建立一个模型。它非常高效：生成的模型非常适合领域驱动设计实现（特别是事件溯源方法），并且可以快速确定上下文和聚合边界。它很简单：它的符号非常简单，并且没有复杂的UML来分??散与会者的注意力，使其无法集中讨论。这很有趣：我总是有一个很棒的工作会议，人们总是参与其中并提出比他们预期更多的东西。问题提得恰到好处，气氛融洽。如果你想了解更多关于事件风暴的知识，请查看Brandolini的书《Introducing EventStorming》。关于领域驱动设计领域驱动设计不是灵丹妙药，就像软件中的一切都取决于上下文一样。根据经验，使用它来保持域模型简单，永远不要增加复杂性。如果你的应用只是以数据为中心，用例主要是对数据库的行和列进行CRUD操作，即增删改查，那么你不需要领域驱动设计。您所需要的只是一个位于数据库之上的漂亮前端。如果您的应用程序的用例少于30个，最好使用像Symfony或Laravel这样的框架来简单地处理您的业务逻辑。然而，如果您的应用程序有超过30个用例，您的系统可能会陷入一个可怕的大泥球。如果您知道您的系统无疑会变得越来越复杂，那么您应该考虑使用领域驱动设计来处理这种复杂性。如果您不了解您工作的领域，那么应用领域驱动设计对您来说将变得复杂，因为它们是新的并且以前没有人解决过。在这种情况下，您最需要与领域专家密切合作才能获得正确的模型。应用领域驱动设计的棘手部分并不容易。投资于业务领域、术语、文献而不是代码堆需要时间和精力。您需要领域专家的承诺才能参与该过程。这需要开放、友好的持续交流，将他们的口头语言翻译成我们的软件模型。此外，我们应该尽量避免使用技术思维，而应该首先认真思考对象的行为和通用语言。策略总结为了对领域驱动设计策略部分进行总体概述，我们将使用JimmyNilsson的书《应用领域驱动设计与模式》中的一种方法，该方法考虑两个空间：问题空间和解决方案空间。在问题空间内，领域驱动设计使用领域和子领域来制定和分类公司想要解决的问题。在在线旅行社(OTA)的示例中，问题是处理机票、酒店预订等事务。此类字段可以规划为不同的子字段，如价格、库存、用户管理等。在解决方案空间中，领域驱动设计提供了两种模式：有界上下文和上下文映射。它的目标是通过定义它们的交互和这些交互的细节来定义如何为所有已识别的子域提供实现。继续OTA示例，每个子域问题都将通过限界上下文实现来解决。例如，由价格管理子域团队开发的自定义Web应用程序，以及用于用户管理子域的开箱即用的解决方案。上下文映射将显示每个限界上下文如何与其他限界上下文相关。在上下文映射中，我们可以看到两个限界上下文（例如：客户-供应商、合作伙伴）之间存在什么形式的关联。理想情况下，每个子域都将由限界上下文实现，但情况可能并非总是如此。在实施方面，遵循领域驱动设计，您最终会得到一个分布式架构。如您所知，分布式架构远比单一架构复杂，那么为什么这种方法很有趣，尤其是对于大型复杂公司而言？是不是真的值得吗？是的，这是值得的！分布式架构已被证明可以提高整体企业生产力，因为它为您的产品定义了边界，允许专门的团队开发它。如果你需要解决的领域问题不是很复杂，应用领域驱动设计的战略部分会增加不必要的开销并减慢你的开发速度。如果你想深入了解领域驱动设计的战略部分，你应该阅读VaughnVernon的书《实现领域驱动设计》的前三章，或者EricEvans的《领域驱动设计：软件核心复杂性应对之道》，这两本书都是专门讲这方面的。相关趋势：微服务和独立系统还有其他几个遵循领域驱动设计的相关运动现在正在蓬勃发展，微服务和独立系统就是很好的例子。JamesLewis和MartinFowler在微服务资源指南中定义微服务：微服务架构风格是一种将单个应用程序的开发分解成小服务的方法，每个小服务都有自己独立的进程和轻量级的通信机制，通常是带有HTTP的API资源。这些服务围绕其业务能力构建，可以独立部署、自动升级和集中管理。服务可以用不同的编程语言编写，使用不同的数据存储技术。如果您想了解有关微服务的更多信息，他们的指南是一个很好的起点。微服务与领域驱动设计有何关系？正如SamNewman《微服务设计》一书中所解释的那样，微服务是领域驱动设计的限界上下文的实现。除了微服务，另一个相关趋势是自包含系统(SCS)。根据自包含系统官网的解释：自包含系统是一种架构，着重于将功能分离成许多独立的系统，这些独立的系统相互协作，提供一个完整的逻辑系统。这可以避免单体系统不断增长并最终变得无法维护的问题。纵观过去几年，我们看到很多大中型项目都从中受益。其思想是将一个大系统分解成一些较小的自包含系统，按照如下确定的规则（官网也明确了自包含系统的七大特征）：每个自包含系统都是一个自治的web应用。包括在自包含系统中处理数据的所有逻辑和呈现Web界面的所有代码。一个独立的系统可以完全自主地处理它的所有用例，而不依赖于其他可用的系统。每个独立的系统都由一个团队管理。这并不一定意味着只有一个团队可以更改代码，但所有者团队可以最终决定代码库中的内容，例如合并，拉取请求。不同的独立系统或第三方系统之间的通信在任何情况下都应该是异步的。特别是，其他自包含或扩展系统不应同步访问自包含系统内的请求/回复。这有助于解耦系统并减少失败结果，从而支持自治。它的目的是关于时间解耦：即使其他自包含系统暂时离线，一个自包含系统也可以很好地工作。即使通信技术级别是同步的，例如复制数据或缓存请求，这也是可能的。具有可选服务API的独立系统。由于每个独立系统都有自己的WebUI来与用户交互，因此不需要UI服务。即便如此，为移动客户端或其他独立系统而存在的API仍然有用。每个独立系统都必须包含数据和逻辑。两者都需要真正实现任何有意义的功能。一个独立的系统应该自己实现所有的功能，所以两者不能分开。独立系统通过自己的UI将功能交到最终用户手中。所以自包含系统不应该与其他自包含系统共享UI。自包含系统可能仍然依赖于其他系统。然而，异步集成意味着即使在其他自包含系统不可用时它也应该工作。为避免紧耦合，自包含系统不应与其他自包含系统共享业务代码。也许通过创建一个独立的系统或公共库，例如：数据驱动层或身份验证客户端。例如，练习与同事讨论分布式架构的优缺点。考虑不同的语言、部署流程、职责等。总结本章内容：领域驱动设计与技术无关；它的价值实际上在于专注于您工作领域中的模型。每个人都参与领域发现的过程，开发人员和领域专家使用同一种语言共同构建知识，即共同语言。领域驱动设计提供战术和战略建模工具来设计高质量的软件。战略设计聚焦业务方向，明确内部关系，以清晰的强边界严格保护每项业务服务。策略为迭代设计提供了有用的构建块。领域驱动设计只有在清晰的上下文中才有意义。它不是解决软件中所有问题的灵丹妙药，所以是否使用它应该根据手头工作的复杂程度来决定。领域驱动设计是一项长期投资；这需要长期的努力。开发人员需要与领域专家密切合作，同时从业务角度思考问题。最后，您还需要考虑业务中的客户因素。实施领域驱动设计需要付出努力。如果简单，每个人都可以写出高质量的代码。准备好，因为你即将开始学习如何编写这段代码，并且在阅读的过程中，你将能够完美地描述你公司现有的业务。享受车程！
