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

战术模式是DDD的关键
DDD不是面向对象设计的书，也不是以代码为中心的哲学或模式语言。但是，如果您在网上搜索有关DDD的文章，那么您会错误地认为它只是少数几种实现模式，因为DDD上的大多数文章和博客都关注建模模式。开发人员更容易看到代码中实现DDD的战术模式，而不是业务用户和团队之间的对话，这是他们不关心或不理解的领域。这就是为什么DDD有时被错误地认为只是由实体，价值对象和存储库组成的模式语言。实际上，您可以在不创建富域模型或使用存储库的情况下实现DDD。
DDD不仅关注软件设计模式，更关注通过协作解决问题。
Evans介绍了使用软件设计模式的技术，以便使用泛在语言实现由开发团队和业务专家创建的模型。但是，如果没有分析和协作的实践，编码实现本身就意味着很少。
DDD不是以代码为中心的;它的目的不是为了制作优雅的代码。软件仅仅是DDD的工件。
DDD是一个框架DDD不需要特殊的框架或数据库。在代码中实现的模型遵循POCO（Plain Old C＃Object）原则，该原则确保它没有任何基础结构代码，因此没有任何东西会分散其以域为中心的目的。面向对象的方法对于构建模型很有用，但它绝不是强制性的。
DDD在架构上是不可知的，因为没有必须遵循的单一架构风格来实现它。在埃文斯的文本中提出了分层的建筑风格，但这不是唯一的选择。架构样式可能会有所不同，因为它们应该应用于有界上下文级别而不是应用程序级别。单个产品可以包括一个遵循以事件为中心的体系结构的有界上下文，另一个使用分层的富域模型，第三个应用活动记录模式。

DDD是一个Silver Bullet DDD可能需要付出很多努力，它需要迭代开发方法，参与业务和智能开发人员。所有软件项目都可以从DDD的分析实践中受益，例如提取问题域以及隔离代表域逻辑的代码模型等战略模式。但是，并非所有人都需要DDD的战术模式来构建丰富的域模型。普通域不具备复杂程度，因为它们很少或没有域逻辑。例如，在创建简单的博客应用程序时应用所有DDD模式会浪费时间和成本。

重点
➤域驱动设计（DDD）是一种开发理念，旨在管理为复杂问题域编写的软件的创建和维护。
➤DDD是模式，原则和实践的集合，可应用于软件设计以管理复杂性。
➤DDD有两种类型的模式。战略模式塑造了解决方案，而战术模式则用于实现丰富的领域模型。战略模式对任何应用程序都很有用，但战术模式仅在您的模型足够丰富的域逻辑时才有用。
➤将大型问题域提升到子域可以揭示核心域 - 最有价值的区域。并非系统的所有部分都设计得很好;团队必须将更多时间投入到产品的核心子域中。
➤为每个子域创建一个抽象模型来管理域问题。
➤使用无处不在的语言将分析模型绑定到代码模型，以便开发团队和领域专家协作设计模型。学习和创建语言来沟通问题域是DDD的过程。代码是工件。
➤为了保持模型的完整性，它在有界上下文中定义。该模型与应用程序的基础架构问题隔离开来，将技术复杂性与业务复杂性分开。
➤如果模型或多个团队在工作中的术语存在歧义，则可以在较小的有界上下文中拆分和定义模型。
➤DDD并未规定任何特定的开发架构风格，它只能确保模型与技术复杂性保持隔离，以便它可以专注于域逻辑问题。
➤DDD重点关注核心领域，与领域专家的协作和探索，实验以产生更有用的模型，以及理解复杂问题领域中的各种上下文。
➤DDD不是一种模式语言，它是一种专注于交付的协作理念，通信起着核心作用。
➤DDD是一种以语言和域为中心的软件开发方法。