什么是领域？

要定义，我们首先应该确定我们在此背景下（以及一般发展中）的含义。通用字典的定义是：“知识或活动领领域”。从这一点深入研究，在软件工程领领域通常是指应用程序打算应用的主题区领域。换句话说，在应用开发过程中，是"应用逻辑围绕的知识和活动领领域"。domain-driven design``domain``domain``domain``domain

在软件开发过程中使用的另一个常见术语是或，这可能是更广为人知的许多开发人员作为。应用程序是指用于创建和修改建模数据（参见：OOAD）如何相互交互的更高级别规则。domain layer``domain logic``business logic``business logic``business objects

什么是领域驱动设计？

最初由程序员 Eric Evans 在 2004 年出版的《领域驱动设计：解决软件核心的复杂性》一书中介绍并广受欢迎，是该概念的扩展和应用，因为它适用于软件的开发。它旨在通过将软件的相关部分连接到不断发展的模型中来简化复杂应用程序的创建。 关注三个核心原则：domain-driven design``domain``DDD

  • 专注于核心和 。domain``domain logic
  • 基于模型的复杂设计。domain
  • 不断合作，以改进应用模式，解决任何新出现的问题。domain experts``domain

Evans 的领域驱动设计进一步定义了在描述和讨论实践时有用的一些常用术语：DDD

  • 上下文：决定其含义的单词或语句的设置。有关模型的陈述只能在上下文中理解。
  • 模型：一个抽象系统，描述一个选定的方面，并可用于解决与之相关的问题。domain``domain
  • 统一语言：一种围绕所有团队成员构建并用于将团队的所有活动与软件连接起来的语言。domain model
  • 边界上下文：定义和适用特定模型的边界（通常是子系统或特定团队的工作）的描述。

分层

Domain-driven design`还定义了一些高级概念，这些概念可以相互配合使用以创建和修改：`domain models
  • 实体：一个由其一致的连续性线程来识别的，而不是传统的，这是由它们定义的。object``objects``attributes
  • 价值对象：有，但没有明显身份的（不变的）。immutable``object``attributes
  • 领域事件：用于记录与系统内模型活动相关的离散事件的对象。虽然系统中的所有事件都可以被跟踪，但只针对所关心的事件类型创建 a。domain event``domain experts
  • 聚合：组周围有定义边界的组组。而不是允许每一个或执行所有行动本身，项目集体被分配一个单一的项目。现在，外部对象不再能够直接访问每个人或内部，而是只能访问单个项目，并用它来将指令传递给整个组。此实践与我们在设计模式系列中涵盖的许多实际编码实践相关联。entities``value objects``entity``value object``aggregate``aggregate root``entity``value object``aggregate``aggregate root
  • 服务：本质上，a 是一种不自然地不属于业务逻辑范围的操作或业务逻辑形式。换句话说，如果某些功能必须存在，但它不能与一个或，它可能是一个。service``objects``entity``value object``service
  • 存储库：不要与常见混淆，a 的含义是使用全球接口提供访问所有和特定集合中的访问。应定义方法，以便创建、修改和删除其中的对象。但是，通过使用它进行数据查询，目标是从业务逻辑中删除此类数据查询功能。version control repositories``DDD``repository``service``entities``value objects``aggregate``aggregate``repository``service``object models
  • 工厂：正如我们已经通过一些设计模式文章讨论过的，建议使用一种，它概括了创建复杂对象的逻辑，并确保客户对对象操作的内部工作不了解。DDD``factory``aggregates
Domain-driven design`也强调越来越受欢迎的做法，要求整个开发团队使用一个共享代码存储库，并推动承诺每天（如果不是一天多次）。自动过程在工作日结束时执行，该过程检查整个代码库的完整性，运行自动单元测试、回归测试等，以快速检测最新提交中可能引入的任何潜在问题。`continuous integration

领域驱动设计的优势

  • 轻松沟通：由于早期强调建立与项目相关的共同语言，团队通常会发现整个开发生命周期的沟通要容易得多。通常，在讨论应用程序的各个方面时，需要的技术术语较少，因为早期建立的术语可能会定义更简单的术语来指那些更技术性的方面。ubiquitous``domain model``DDD``ubiquitous language
  • 提高灵活性：由于如此大量地基于概念，几乎所有内容都将基于一个对象，因此，将相当模块化和封装。这允许定期、连续地更改和改进各种组件，甚至整个系统。DDD``object-oriented analysis and design``domain model
  • 强调界面领域：因为是围绕项目内的概念和建议构建的实践，因此通常会生成准确适合和代表手头应用的应用程序，而不是首先强调 UI/UX 的应用程序。虽然需要一个明显的平衡，重点意味着一种方法可以产生一个产品，与观众产生良好的共鸣。DDD``domain``domain experts``DDD``domain``domain``DDD``domain

领域驱动设计的缺点

  • 需要强大的领域名专业知识：即使拥有最精通开发的技术头脑，如果没有团队中至少有一个人知道应用程序拟应用的主题区领域的确切来回，这一切都是徒劳无功的。在某些情况下，可能需要整合一个或多个外部团队成员，他们可以在整个开发生命周期中起作用。domain expert``domain-driven design``domain experts
  • 鼓励迭代实践：虽然许多人会认为这是一个优势，但不可否认的是，实践严重依赖不断的迭代和持续集成，以便构建一个可塑性项目，在必要时可以自行调整。有些组织在这些做法上可能有困难，特别是如果他们过去的经验在很大程度上与不太灵活的发展模式有关，例如瀑布模型等。DDD
  • 不适合高技术项目：虽然非常适合具有大量复杂性（复杂和复杂的应用），但不太适合具有边际复杂性的应用程序，但反过来又具有很大的技术复杂性。由于如此强调（和重要性）产生适当的项目，然后项目的基础，一个技术上极其复杂的项目可能具有难以把握的能力，因此可能会导致问题，也许当团队所有成员都不完全理解技术要求或限制时。DDD``domain``business logic``DDD``domain``DDD``domain experts``ubiquitous language``domain model``domain experts