问题标签 [domain-driven-design]

在讨论最近一个项目的规格和功能要求时，我们正在与领域专家讨论荷兰语的会计术语，因为整个团队和客户都是荷兰语母语人士。

当开发开始时，我们自然地用英文实现了领域类和接口，因为我们用英文编写了所有代码。尽管我注意到与客户的后续会议有时让他们感到困惑，尤其是当开发人员讨论实施细节并因此使用英文术语时。

您对此有何经验？

PS：我知道 Stack Overflow 上还有其他一些关于您是否应该用您的母语编写代码的帖子，但这个问题更多的是关于创建和使用所有开发人员、客户和领域专家都能理解的普遍存在的语言。

如何使用存储库模式以事务方式封装多个实体的保存？例如，如果我想添加一个订单并根据该订单创建更新客户状态，但只有在订单成功完成后才这样做？请记住，对于此示例，订单不是客户内部的集合。他们是他们自己的实体。

这只是一个人为的例子，所以我并不关心订单是否应该或不应该在客户对象内，甚至在同一个有界上下文中。我并不真正关心将使用什么底层技术（nHibernate、EF、ADO.Net、Linq 等）。我只想看看在这个公认的人为设计的全有或全无操作示例中某些调用代码可能是什么样子。

在 NHibernate 中，我可以使用工厂来构建复杂的聚合对象（实体）吗？如果是，那怎么办？如果没有..那么你的方法是什么？

您如何在将值对象（规范示例是地址）实现为不可变对象或结构之间进行选择？

选择其中一个是否有性能、语义或任何其他好处？

假设您有一个包含大量产品/客户/订单的数据库，并且代码库 (java/c#) 包含所有业务逻辑。在夜间，需要分批将数据导出到平面文件，然后通过 ftp 将它们传输到专有系统。

我们应该如何做到这一点“将数据库写入平面文件？最佳实践是什么？

一些想法：

• 我们可以创建一个存储过程并使用 f.ex ssis 来获取数据吗？如果我们有一个“batch-output-database-table”也许我们可以做到这一点，但如果我们必须在文件写入之前执行逻辑就不行了？

• 我们可以使用与域的其余部分相同的存储库/业务逻辑来完成托管代码中的所有逻辑吗？（与存储过程解决方案相比，这可能是一个缓慢的过程）

• 如果域服务的唯一接口是 Web 服务（每个请求可能需要“很长时间”），“最佳实践”会改变吗？

假设一家公司正在构建一个全新的应用程序。该应用程序遵循 DDD 原则。旧代码库有很多他们想要转换为新代码库的产品（或公司的另一个“实体”）。

这项工作应该怎么做？通常，使用例如 ssis 导入会更快、更容易——从一个数据库传输到另一个数据库。但是这里的主要问题是跳过了很多 BusinessRules（在 DomainLayer 中的托管代码中实现）......如果开发人员说：“我控制它。规则被复制为 sql 脚本.. 。”

我们是否应该将托管代码库导入 SQL Server（至少这在 .NET 和 MS SQL Server 中是可能的）？或者我们应该在托管代码中创建一个导入脚本，以便在将实体保存在数据库中时遍历域中的所有层？...（可能需要很多小时..）

你怎么认为？

我正在为 MVC 应用程序构建一些存储库，并且我正在尝试提出在存储库之间划分职责的正确方法。在大多数情况下，这是显而易见的。但是有一种特殊情况，我不确定正确的答案是什么。

此应用程序的用户需要为其员工跟踪多种类型的时间。为简单起见，我们只考虑两个。我称它们为“考勤卡”和“考勤”。这两者之间差异的确切性质并不重要，但您应该注意最终用户将它们视为完全独立的数据。不过，我认为，他们认为它们完全独立的数据的原因是他们过去从未真正有机会看到它们在一起。这两种类型的记录在编辑记录方面具有几乎完全不同的业务规则，但一般来说，它们也是员工在特定时间所处位置的两种记录。这两种时间记录有很多共同的属性，比如总小时数，以及为其收集时间的员工。这两种类型还具有一些完全独特的单个类型的属性。我们将这些“额外”属性保存在另一种类型的实例中。所以一般的结构是这样的：

所以问题是，这里需要多少个存储库？

1 个存储库

只有一个存储库的设计将公开返回“时间卡”、“出勤”记录或在一个列表中返回两种类型的方法。这对于存储库的客户来说相当方便，但在我看来，它有成为一个非常胖的类的真正危险。我认为仅用于“考勤卡”的存储库已经成为系统中最大的存储库之一，即使由于涉及复杂的业务规则而无需处理“出勤”。

2 存储库

另一种设计将有一个“考勤卡”存储库和另一个“考勤”记录存储库。这样做的好处是，例如“考勤卡”的业务规则本身就在一个地方。但我也想有一种方法来获取所有时间记录的列表，无论类型如何。目前尚不清楚在这种情况下使用哪个存储库。两个都？

3 存储库

具有一个用于“时间卡”的存储库、另一个用于“出勤”记录的存储库以及提供所有时间记录的只读列表的第三个存储库的设计也是可能的。与 2 存储库设计一样，这具有优势，例如，“时间卡”的业务规则位于一个位置。现在很清楚从何处获取组合列表。但是我发现我可以从两个不同的存储库中获得相同的记录有点奇怪。

杂交种

混合方法将使用单个存储库，但将任何业务规则代码（包括记录选择）移动到单独的类型中。在此示例中，单个“时间记录存储库”将聚合“时间卡”和“出勤”时间的业务规则实现类的实例。我认为这是我现在喜欢的方法。

其他？

我错过了什么？一种设计优于另一种设计有什么令人信服的论据吗？

我们这里有一个相当大的应用程序，我考虑对其进行一些重构以遵循 DDD 人员的指导。

目前，它的第一个问题是有界上下文和上下文映射。也许我只是不了解它，但在我看来，除法是不可能的。例如，我们到处都有用户对象，它是完全相同的用户对象：显示名称、ID 和角色。还有另一个例子：我们有 CatalogItem 对象来帮助我们对整个地方的其他实体进行分类。我们是否必须引入限界上下文依赖项？除了那个烦人的电子商务样本之外，这件事有什么指导吗？

我目前正在重构一个即将结束的项目的一些代码，我最终将大量业务逻辑放入服务类而不是域对象中。此时，大多数域对象只是数据容器。我决定在服务对象中编写大部分业务逻辑，然后将所有内容重构为更好、更可重用和更易读的形状。这样我就可以决定哪些代码应该放在域对象中，哪些代码应该分拆到它们自己的新对象中，以及哪些代码应该留在服务类中。所以我有一些代码：

这段代码似乎可以很好地添加到域对象中，因为它的唯一输入参数是域对象本身。似乎是一些重构的完美候选者。但唯一的问题是这个对象调用了另一个对象的存储库。这让我想把它留在服务课上。

我的问题是：

1. 你会把这段代码放在哪里？
2. 你会打破这个功能吗？
3. 遵循严格的领域驱动设计的人会把它放在哪里？
4. 为什么？

谢谢你的时间。

编辑注意：不能在这个上使用 ORM，所以我不能使用延迟加载解决方案。

编辑注2：我不能改变构造函数来接受参数，因为可能的数据层如何使用反射来实例化域对象（不是我的想法）。

编辑注3：我不认为批处理对象应该能够汇总任何应用程序列表，似乎它应该只能汇总该特定批次中的应用程序。否则，将函数留在服务类中对我来说更有意义。

到目前为止，我已经了解实体对象有一个 ID，而值对象没有，但在最常见的示例中，您有一个附有地址值对象的人员实体。创建单独的地址对象而不是仅将地址属性保留在 Person 实体中的最大优势是什么？