2

我已经开始学习 DDD 并且我有几个问题，以便我可以提高对它的理解。

所以典型的 DDD 架构是这样的

领域层 => 该层应该与技术无关，并且应该包含以下内容

Domain.Entities（与持久层实体不同，应该只包含验证规则？任何其他域业务应该去这里吗？）

Domain.ValueObjects（不需要在域中唯一的对象，应该只包含验证规则）

Domain.Services（该层应包含业务逻辑，尽管与聚合相关，但不适合聚合本身。需要多个 Domain.Entities 和/或 Domain.ValueObjects 协作的操作的编排器）

Domain.Factories（这个层不知何故还没有完全理解，我的意思是它的责任是创建聚合或什么？）它纯粹是工厂设计模式还是与它不同？

Domain.Repositories（这一层也是模棱两可的，除了我知道这一层负责与外部服务通信，它应该处理什么类型的业务逻辑？）

反腐败层（这一层应该作为域层和应用层之间的网关，它应该负责将响应和请求从一层转换到另一层）

应用层 => 只能用于以客户端易于理解的格式公开数据。过滤在这一层完成（Linq-To-SQL）/（Linq-To-Entity）

客户端（最后一层）=> 应该没有任何逻辑，只公开应用层服务提供的模型。

我看到的其他图层

Shared.Kernel（跨多个限界上下文共享的Domain.ValueObjects / Domain.Entites（不是AggregateRoots））

Infrastructure.Domain.Common（在整个域中共享，例如 AggregateRoot、BaseEntity、BaseValueObject 等）

Infrastructure.DataAccess.Provider（例如 EntityFramework / nHibernate/ MongoDriver ，该层应该与谁通信？应用层？

4

3 回答 3

6

DDD 没有定义分层方法。它只是建议使用一个。我建议阅读清洁/六边形/洋葱分层。这种方法与 DDD 一致并得到广泛认可。

六角形

干净的

洋葱

不要让不同的名称欺骗您，方法非常相似，即使不相同。

于 2018-01-08T21:23:22.530 回答
4

老实说，领域驱动设计的前提会根据应用程序需求、业务任务和可能决定应用程序的底层架构而有所不同。领域驱动设计的最简单解释。

  • 数据层：抽象的数据层，将关注点与图形用户界面分离。

  • 领域层：您的业务规则和逻辑，公司要求的基本基础，使命。

  • 服务层：不是必需的，但充当图形用户界面和数据层之间的中介。建模数据到业务实体之间的清晰简洁的转换。

  • 应用层：您的用户界面，以有意义的方式向用户提供核心业务功能。

重要的概念，没有层是相互依赖的。他们都是独立的，互相恭维。您已经涉足了更具体的上下文概念，所有这些概念在每个应用程序中都不相关或可行。

根据您的示例，您可以将您的域向外抽象到该层可能是贫乏的，没有足够的相关或有用信息。传统的分层应用程序，如果以微服务方法、循环方法（清洁架构）或分层方法编写，则可以是域驱动设计。因为每种方法或风格都使用领域驱动设计的基本目的，捕捉业务目的和使命。

应用程序不是领域驱动设计，因为您有一个层。您的应用程序将遵循一系列原则以符合领域驱动设计。这些原则是为了确保您的应用程序适应业务变化。持有代表业务的核心逻辑，同时随着业务目标在公司整个生命周期中的变化而变化。它们经常落入松耦合的一边。

您提到的上述层中有一半是解决问题的复杂模式。所有工具都有一个目的，就像一个模式，螺丝刀用于问题 x，工厂可能解决 x，但存储库可能解决 y。并非每种模式都适合每种用途。它们不是解决问题的千篇一律的解决方案。

关于这个主题有很多材料。福勒、埃文斯、沃恩和无数其他人。

于 2018-01-08T21:24:50.220 回答
2

DDD 的起点是“蓝皮书”：Eric Evans 的域驱动设计

典型的 DDD 架构看起来像

分层架构。Evans 回顾了四个概念层

  • 用户界面
  • 应用
  • 领域
  • 基础设施

在第 4 章（隔离域）中，Evans 指出

专门解决领域问题的软件部分通常只占整个软件系统的一小部分，尽管它的重要性与其规模不成比例。为了应用我们最好的想法，我们需要能够查看模型的元素并将它们视为一个系统......我们需要将域对象与系统的其他功能解耦，这样我们就可以避免混淆域概念与仅与软件技术相关的其他概念或完全忽略该领域......

在“领域层”中，埃文斯认识到两组不同的关注点。

领域实体、价值对象和领域服务在软件中为业务建模（第 5 章）。换句话说，这些元素模拟了您的领域专家将识别的概念。

存储库和工厂是生命周期的关注点 - 不像专家们认为的那样与业务严格相关，而是充当应用层和领域层之间的边界。

在 Evan 的表述中，业务规则的验证通常存在于域实体（而不是域服务）中。正如 OO 风格中常见的那样，域实体结合了状态（域值）和行为（更改规则）——对持久层实体的任何更改（你是对的，不是同一件事）都是由于域执行的代码而发生的实体。

反腐败层更多的是与外部数据源（可能是遗留系统）集成，然后是与应用程序层集成。

在现代应用程序和它所依赖的遗留系统之间实施外观或适配器层。该层在现代应用程序和遗留系统之间转换请求。使用此模式可确保应用程序的设计不受对遗留系统的依赖性的限制。

您可能想查看github上提供的 DDD 示例应用程序。这是一个很好的草图，说明了不同的部分如何组合在一起。

注意：这些天来，分层架构已经被其他一些替代方案所取代，我们开始看到更多使用功能核心（而不是 OO 风格）实现领域模型的工作。

于 2018-01-09T00:00:47.790 回答