问题标签 [domain-driven-design]

我正在一家中型公司开始工作，主要致力于编写与他们的 ERP 系统交互的自定义​​应用程序。这是我第一次做这种工作，所以 ERP 概念对我来说是新的，我正在学习它。

到目前为止，我只编写了两个应用程序，并且学习了数据库模型，并且只学习了完成工作所需的量，但即使数量有限，我也可以开始看到一个大图景。然后我的想法是编写一个库，其中存储了所有映射/模型对象，以便新应用程序可以引用这个库。之后，每个应用程序将创建自己的存储库，将访问权限限制为只访问他们需要的内容和有意义的视角。

我遇到的问题/问题是如何处理（N）Hibernate 映射中的关系。如果我有一个在此基础库中映射的具有完整关系的订单对象，则没有什么能阻止某人永远旅行这些关系（假设我是唯一的程序员......）。因此，从这个意义上说，使用存储库作为一种范围限制根本行不通。

相反，如果我限制此订单对象的 (N)Hibernate 映射中的关系，则存储库会返回一个订单对象，该对象仅与它的范围所需的关系绑定。缺点是我现在必须为每个项目创建映射，而不是拥有一个“映射存储”。

其他人如何处理这个问题？

有点不相关，但我也一直在将可能由多个关系组成的 (N)Hibernate 持久对象转换为一种更适合特定应用程序的单一非持久对象（通常受 UI 影响更大）。这是一件常见的事情，还是我通过获取返回的对象并将它们转换为其他东西来丢弃 (N)Hibernate 的一些好处？

附言。关于 DDD 标签...我不知道这是否是 DDD 详细介绍的内容，但我确实有订购这本书。不过，在本书到达之前，我不确定是否有好的资源可供查看。

我发现了两个崩溃的问题：

• 您应该在领域专家和开发团队 (DDD) 之间使用相同的语言
• 您应该在代码中使用英文命名（.Net 设计指南）

如果领域专家不会说英语怎么办？

领域驱动设计鼓励您使用丰富的领域模型。这意味着所有的领域逻辑都位于领域模型中，并且领域模型是至高无上的。持久性成为一个外部问题，因为理想的领域模型本身对持久性一无所知（例如数据库）。

我一直在一个中等规模的单人项目（> 100k 行 Java）中使用它，我发现了许多优点，主要是它提供的灵活性和可重构性，而不是面向数据库的方法。我可以添加和删除域类，点击几个按钮，一个全新的数据库模式和 SQL 层就会推出。

但是，我经常遇到这样的问题，即我发现很难将富域逻辑与支持应用程序的 SQL 数据库这一事实相协调。通常，这会导致典型的“1+N 查询问题”，即您获取 N 个对象，然后对每个再次触发查询的对象执行一个重要的方法。手动优化此过程允许您在恒定数量的 SQL 查询中执行该过程。

在我的设计中，我允许系统插入这些优化版本。我通过将代码移动到一个“查询模块”中来做到这一点，该模块包含数十个特定于域的查询（例如 getActiveUsers），其中两个都在内存中（幼稚且不可扩展）和基于 SQL（用于部署）的实现。这使我可以优化热点，但有两个主要缺点：

• 我有效地将我的一些域逻辑移动到它并不真正属于的地方，实际上甚至将其推入 SQL 语句中。
• 这个过程需要我仔细阅读查询日志以找出热点在哪里，然后我必须重构代码，通过将其降低到查询中来降低其级别抽象。

有没有更好、更简洁的方法来协调域驱动设计及其富域模型与您不能将所有实体都保存在内存中并因此仅限于数据库后端的事实？

我目前正在从事的项目需要大量搜索/过滤页面。例如，我有一个复杂的搜索页面，可以按数据、类别、单位、...

问题域类很复杂，包含大量的值对象和子对象。

.我想知道人们如何处理 UI 的搜索/过滤/报告。据我所知，我有 3 个选择，但没有一个能让我更快乐。

1.) 将参数发送到 Repository/DAO 以获取 DataTable 并将 DataTable 绑定到 UI 控件。例如到 ASP.NET GridView

在这个选项中，我可以简单地通过域层并查询给定规格的数据库。而且我不必完全构建复杂的域对象。不需要值对象，子对象，.. 直接从数据库中获取数据以显示在 UI 中的 DataTable 中并显示在 UI 中。

但是如果必须在 UI 中显示计算字段，例如方法返回值，我必须在数据库中执行此操作，因为我没有完整的域对象。我必须复制逻辑和 DataTable 问题，比如没有智能感知等......

2.) 将参数发送到 Repository/DAO 以获取 DTO 并将 DTO 绑定到 UI 控件。

在此选项中与上述相同，但我必须为每个搜索页面创建贫血的 DTO 对象。另外对于不同的问题搜索页面，我必须显示问题对象的不同部分。IssueSearchDTO、CompanyIssueTO、MyIssueDTO ....

3.) 将参数发送到 Real Repository 类以获得完全构造的域对象。

我喜欢领域驱动设计和模式。此选项中没有 DTO 或重复逻辑。但在此选项中，我必须创建许多子对象和值对象，这些对象不会在 UI 中显示。此外，它还需要大量的 ob 连接才能获得完整的域对象和针孩子的性能成本对象和值对象。

我不使用任何 ORM 工具也许我可以为这个版本手动实现延迟加载，但它似乎有点矫枉过正。

你更喜欢哪一个？还是我做错了？有什么建议或更好的方法吗？

我们有一个使用复合 UI 应用程序块 (CAB)/智能客户端软件工厂 (SCSF) 构建的复合应用程序。迄今为止，我们的复合应用程序中的每个模块都使用了自己的一组 DTO，并且业务逻辑已在整个模块中重复，包括 UI 层和服务层。我想追求更多领域驱动的方法，以便将业务逻辑封装在一个领域层中，该领域层可以分布到 UI 层和服务层，并且（理想情况下）跨模块。

我们的复合应用程序中同时有多个模块正在开发中，我们需要能够以任何顺序部署它们。理想情况下，我希望我们的模块共享一个通用的域模型，但我担心当我们部署新版本的域模型和一个模块时，我们需要针对域模型对其他模块进行回归测试.

另一种方法似乎是在每个模块中复制域模型，但所有这些代码重复对我来说都很有趣。该行业是否针对这种情况制定了任何最佳实践？

假设您正在与客户的领域专家合作。你意识到（或至少有合理的信念）你对他们问题的模型比他们的更清晰。你如何说服他们他们应该按照你的方式行事。

就我而言，需求的主要推动力是相当清楚的（例如，产品的交易系统）。根据我的经验和研究，我会推荐一个有两个 TraderParties 的 TradeContract。每个 TraderParty 购买一种产品并出售一种产品。如果我必须在 XML 中对组合进行建模，我可以将其建模为：

以上只是安以 20.00 美元从鲍勃那里购买的哈利波特与阿兹卡班囚徒的模型。更抽象地说，这模拟了两方四足交易。为了争论，我们假设使用 XML 的系统验证tradeContract并协调交易。

如果您的领域专家觉得这对他们来说太复杂了怎么办？虽然您可以很容易地承认一些中间步骤来获得上述域模型，但您如何说服他们“咬紧牙关”并尽早使用上述域模型更好？

补充：中小企业提出的模型...

领域专家一直在谈论的是我提出的模型，但看起来他们不相信他们的业务流程还没有准备好。（不过，我认为现在有一些方法可以解决）。

他们立即想要的模型是：

Ann 赠送了 20.00 美元的这个模型。然后必须输入一个单独的事务：

为了建模，她获得了哈利波特的书。我认为这很麻烦，因为我们无法模拟我们的系统是否会欺骗 Ann。同样，交易合约中 Bob 一方也发生了类似的交易碎片化。

我正在编写一个简单的 Web 应用程序，使用 Linq to Sql 作为我的数据层，因为我非常喜欢 Linq2Sql。我最近读了一些关于 DDD 和 TDD 的文章，想试一试。

首先让我感到震惊的是，Linq2Sql 和 DDD 并没有很好。我的另一个问题是寻找测试，我实际上发现很难定义好的测试所以我想问，你发现好的测试用例的最佳技术是什么。

在域驱动设计中，使用工厂在域层中创建域对象似乎是一种很好的做法（而不是使用直接构造函数或 IoC）。

但是在表示层中使用域对象工厂呢？例如，假设我正在根据从演示者获得的用户输入创建域对象。

这是一个示例，假设我有一个配置域对象，该对象具有许多十进制设置。

公共类配置：PersistantObject {

}

为了在域层而不是演示者层中创建这个对象，我必须将这些十进制值中的每一个作为函数参数传递。创建一个笨拙的函数定义和调用。

即 ConfigurationService.CreateConfiguration(温度, ...(x20), 重力);

也许更好的解决方案是在演示者层创建配置对象，并直接从用户输入分配配置对象的所有值，跳过冗长的函数调用。

配置配置 = ConfigurationFactory.CreateNewConfiguration();

配置温度=温度；

..(x20).. = ...;

config.gravity = 重力；

ConfigurationService.SaveNewConfiguration(config);

但我想知道这种方法是否错误，为什么？如果这两种方法都是错误的，那么从用户输入创建长对象的最佳方法是什么？为什么？

谢谢！

默认情况下为您的域对象工厂使用接口是否有意义，或者是否应该只在需要时为工厂类保留接口？

在一个领域驱动的设计中，你要使用一个非贫血的领域模型，你如何决定在你的领域对象和面向服务的方法中实现什么？

编辑：我用一个例子问了这个不同的方式，在这里得到了更好的答案