领域驱动设计(Domain Drive Design)学习分享--DDD的战略模式

DDD是一种软件开发方法，使团队能够有效地管理复杂问题域的软件构建和维护。

并非所有大型软件产品都需要完美设计 - 实际上尝试这样做会浪费精力。开发团队和领域专家使用分析模式和知识运算来将大型问题域提炼为更易于管理的子域。

这种蒸馏揭示了核心子域 - 软件编写的原因。核心领域是正在开发的产品的驱动力;这是它建立的根本原因。 DDD强调需要将精力和人才集中在核心子域上，因为这是最具价值的领域，也是应用程序成功的关键。
关注工作重点的清晰度还可以使团队能够为系统中一些不太重要的部分寻找开源的现成解决方案，这意味着他们有更多的时间专注于重要的事情，并确保核心域名不会成为BBoM。

发现核心域有助于团队了解他们为何生产软件以及软件对业务成功的意义。对业务意图的欣赏将使开发团队能够识别并将其时间投入到系统的最重要部分。随着业务的发展，反过来必须是软件;它需要适应性强。为应用程序的关键领域投入代码质量将有助于它随业务而变化。如果软件的关键区域与业务领域没有协同作用，那么随着时间的推移，设计可能会腐烂并变成泥球，从而导致难以维护的软件。

创建解决域问题的模型在解决方案空间中，为每个子域构建软件模型，以处理域问题并使软件与业务轮廓保持一致。此模型不是现实生活的模型，而是为满足业务用例的要求而构建的抽象，同时仍保留业务域的规则和逻辑。开发团队应该将重点放在模型和域逻辑上，就像应用程序的纯技术方面一样。为避免意外的技术复杂性，模型与基础架构代码保持隔离。

所有模型都不是平等的;根据每个子域的复杂性需求使用最合适的设计模式，而不是将整体设计应用于整个系统。
子域的模型不是产品成功的核心，也不是复杂的子域，不需要基于丰富的面向对象设计，而是可以使用更多的过程或数据驱动的体系结构。

使用共享语言启用建模协作模型是通过领域专家和开发团队的协作构建的。
使用称为泛在语言（UL）的不断发展的共享语言来实现通信，以高效且有效地将软件模型连接到概念分析模型。软件模型通过使用与其结构和类设计相同的UL术语绑定到分析模型。在编码级别发现的见解，概念和术语在UL中进行复制，因此也在分析模型中进行复制。同样，当企业在分析模型层面揭示隐藏的概念时，这种洞察力会被反馈到代码模型中;这是使领域专家和开发团队能够协作发展模型的关键。

从模糊和腐蚀中分离模型模型位于有界上下文中，该上下文定义了模型的适用性并确保其完整性得以保留。较大的模型可以拆分为较小的模型，并在单独的有界上下文中定义，其中存在术语歧义或多个团队工作以进一步降低复杂性。

有界上下文用于围绕模型形成保护边界，有助于防止软件演变为BBoM。这是通过允许整体解决方案的不同模型在明确定义的业务环境中发展而不会对系统的其他部分产生负面的，波动的影响来实现的。模型与基础架构代码隔离，以避免合并技术和业务概念的意外复杂性。有界上下文还通过将模型与第三方代码隔离来防止模型的完整性。
比较图1-3和图1-2中的图表。

该图显示了如何将DDD的战略模式应用于软件以管理大问题域并保护其中的离散模型。

MUD的大球并不总是一个反面图并不是大型应用程序的所有部分都将被完美地设计 - 它们也不需要。 虽然不建议按照BBoM模式构建整个企业软件堆栈，但您仍然可以使用该模式。 可以构建低复杂度或不太可能投资的区域，而无需完美的代码质量; 工作软件足够好。 有时反馈和首次上市是产品成功的核心; 在这种情况下，无论架构如何，尽快获得工作软件都具有商业意义。 在企业认为产品成功并值得长期投资后，代码质量总能得到提升。 获得BBoM优势的关键是定义围绕有界上下文的上下文，这些上下文使用BBoM来避免它们破坏核心子域。

了解上下文之间的关系DDD理解需要确保团队和业务明确单独的模型和上下文如何协同工作，以解决跨子域的域问题。
上下文地图可以帮助您了解更大的图景;它们使团队能够了解存在哪些模型，他们负责什么以及他们的适用性边界在哪里。这些地图揭示了不同模型如何交互以及它们交换哪些数据来实现业务流程。
连接之间的关系以及更重要的是位于它们之间的过程的灰色区域通常不会被业务捕获或很好地理解。
DDD的战术模式DDD的战术模式，也称为模型构建块，是一组模式，有助于为复杂的有界上下文创建有效的模型。战术模式集合中提出的许多编码模式在Evans的文本之前已被广泛采用，并由Martin Fowler在企业应用程序架构模式和Erich Gamma等人编目。在设计模式中：可重用的面向对象软件的元素。这些模式并不适用于所有模型，每个模型都必须根据自己的优点采用正确的建筑风格。
问题空间和解决方案空间本节中详述的所有模式都有助于管理问题的复杂性 - 即问题空间或他们管理解决方案中的复杂性 - 即解决方案空间。问题空间（如图1-4所示）将问题域提炼为更易于管理的子域。 DDD在问题空间中的影响是揭示什么是重要的以及在哪里集中精力。在下一章中，我们将详细介绍有助于降低问题空间复杂性的模式。
DDD的解决方案，如图1-5所示，涵盖了可以塑造应用程序架构并使其更易于管理的模式。

领域驱动设计的实践和原则虽然有许多DDD模式，但有许多实践和指导原则是其理念成功的关键。构成DDD本质的这些关键原则经常被忽略，因为太多的重点放在用于创建软件模型的战术设计模式上。
专注于核心域DDD强调需要将最大的精力集中在核心子域上。核心子域是产品的一个区域，它将成为成功与失败之间的区别。这是产品的独特卖点，它是建造而非购买的原因。核心领域是产品的一个领域，它将为您提供竞争优势并为您的企业创造真正的价值。所有团队都了解核心领域是至关重要的。
通过协作学习DDD强调了开发团队和业务专家之间协作的重要性，以生成解决问题的有用模型。如果没有业务专家的这种合作和承诺，很多知识共享将无法进行，开发团队也无法深入了解问题领域。同样，通过协作和知识处理，企业有机会更多地了解其领域。
通过探索和实验创建模型DDD将分析和代码模型视为一体。这意味着技术代码模型通过共享UL绑定到分析模型。分析模型的突破导致代码模型的改变。代码模型中的重构揭示了更深入的洞察力，这再次反映在业务的分析模型和心智模型中。只有当团队有时间探索模型并试验其设计时，才会出现突破。花时间进行原型设计和实验可以帮助您塑造更好的设计。它还可以揭示糟糕的设计是什么样的。埃里克埃文斯建议，对于每个好的设计，必须至少有三个不好的设计，这将阻止团队停在第一个有用的模型。
通信有效描述为表示问题域而构建的模型的能力是DDD的基础。这就是为什么毫无疑问，DDD最重要的一个方面就是创建UL。如果没有共享语言，业务和开发团队之间为解决问题而进行的协作将无效。在团队之间的知识聚会中产生的分析和心理模型需要共享语言将它们与技术实现绑定。
如果没有有效的方法在问题领域内交流想法和解决方案，设计突破就不会发生。
正是UL的协作和构建使得DDD如此强大。它可以更好地理解问题领域（针对业务和开发团队）有效沟通。
这些关键价值对项目产生了巨大影响，因为虽然技术框架和方法很重要，但DDD在分析和理解最终使软件产品成功的问题域方面同样重要，甚至更重要。

了解模型的适用性构建的每个模型都在其子域的上下文中理解，并使用UL进行描述。然而，在许多大型模型中，UL内部可能存在歧义，组织的不同部分对共同术语或概念有不同的理解。 DDD通过确保每个模型都有自己的UL（仅在特定上下文中有效）来解决此问题。每个上下文定义语言边界;确保模型在特定的上下文中被理解，以避免语言模糊。因此，具有重叠项的模型被分成两个模型，每个模型在其自己的上下文中明确定义。在实施方面，战略模式可以强制执行这些语言边界，使模型能够孤立地发展。这些战略模式导致有组织的代码能够支持变更和重写。
不断发展模型任何开发复杂系统的开发人员都可以编写好的代码并在短时间内维护它。但是，如果源代码和问题域之间没有协同作用，继续开发可能最终会导致难以修改的代码库，从而产生BBoM。 DDD通过强调团队来持续关注模型对当前问题的有用性来帮助解决这个问题。它挑战团队在获得领域洞察力时发展和简化复杂的域模型。 DDD仍然没有灵丹胆，需要奉献精神和不断的知识处理来生产可维护多年而不仅仅是几个月的软件。新的商业案例可能会破坏以前的使用情况