问题标签 [rich-domain-model]

我想要一个全局/应用级别设置，我想在我的富域模型中使用它。

我有一种方法可以根据传递的参数进行一些计算。

这可能不是最好的示例，并且可能看起来不像属于域模型的方法，但我尽量保持简单，以便您理解问题。

现在假设我在其他领域模型中有很多这样的方法，它们也接受CalculationMethod他们的方法。我想要一个全局设置，这样我就可以全局设置一个计算方法，以便所有将其作为参数的方法都可以使用它。

一种解决方案是每次调用此方法时都读取配置。

我想知道是否有更好的方法让我可以CalculationMethod全局设置并且永远不会传递它，而是拥有某种静态变量（单例）来保存计算方法并直接在我的方法中读取它而不传递它。但我认为那时会有线程安全的问题。

我不能在构造函数中传递它，因为它不属于我的域模型。

如何处理这类问题？有没有比我提到的两个更好的方法？

我在 Mark Seemann 的回答下的评论中问了这个问题：DDD 中的应用程序级设置？

我知道 DDD 建议为每个业务操作创建单独的用例。

假设您有一个 Player 聚合。它具有地址值对象。

DDD 不允许在层上创建UpdatePlayer()方法。PlayerApplication相反，我们应该做的是创建企业感兴趣的特定用例。所以，而不是UpdatePlayer()，我想拥有RelocatePlayerTo(Address newAddress)。

如果搬迁后，我发现我在 newAddress 中出错了怎么办？如何调整地址？例如，我拼错了街道名称，或者输入了错误的单位编号。

我应该创建一个新的用例AdjustPlayerAddress吗？还有一个新的 DomainEvent PlayerAddressHasBeenAdjusted？

我在运行我的项目并通过我的 Register.cshtml 视图发送 POST 时遇到错误。请参阅下面的错误：

InvalidOperationException：无法创建“AdoteRJ.Models.Adotante”类型的实例。模型绑定的复杂类型不能是抽象类型或值类型，并且必须具有无参数构造函数。或者，给“模型”参数一个非空的默认值。Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ComplexTypeModelBinder.CreateModel(ModelBindingContext bindingContext)

在我重构 MyEntity 类 (Adotante) 之后，这个错误开始发生，添加了一些复杂的类型，以使其成为一个富域。由于某种原因我还没有发现，这个错误开始了，POST 得到一个错误 500，尽管表单数据已成功填写（我在开发工具的标题上检查了它）

我正在使用 .NET Core 2.1

另外，我在下面发现了这个问题，有同样的问题，但它的答案并没有解决它 - 如果你添加一个空的构造函数，错误就会消失，但是表单是空的...... 模型绑定的复杂类型不能是抽象的或值类型并且必须有一个无参数的构造函数

我的代码：

我的 ValueObject 类之一的示例：

我的 Register.cshtml 类上的表单：

我是域驱动设计的新手，在编写域模型时有一件事困扰着我。如何处理域验证？

我正在设计图书馆管理系统，用户可以在其中搜索书籍并查看书籍是否在库存中。如果不是，用户可以创建图书请求，以便创建某种队列。规则是我们没有任何书存货。现在我有关于书籍实体内部数量的信息，这不是问题，但是如果我有不同的有界上下文来请求书籍和书籍目录怎么办。然后我必须以某种方式联系另一个垂直/服务并在创建书籍聚合之前询问（验证）书籍数量为零。

我也在检查用户是否有有效的会员卡，他是否已经借过书，用户是否有任何书的主动请求。

困扰我的事情。

由于验证，在将其传递给域模型之前，我需要知道究竟要包含什么。我不确定这是最安全的方法，因为我的验证准确性将取决于规范/查询等。

另一个非常重要的事情。当应用程序层方法开始执行并且某些内容无效时，客户端将仅获得已执行代码的验证消息，并且很有可能存在更多阻止代码执行的内容。如果用户正在填写一些表格，这可能真的很不方便。

解决这个问题的第一个想法。

我有命令/处理程序架构，并且我正在使用 MediatR，所以我正在考虑在命令和处理程序之间移动域验证，这将解决我现在的问题，但是这种方法将跨有界上下文传播域知识，并且域模型不够聪明防止无效的动作。更准确地说，我需要在执行应用程序方法（处理程序）之前考虑我需要验证的内容。

所以我真的很好奇。是否有任何明确的方法来处理域模型内的域验证？

有一个概念谈到了将 与 分离persistent layer以domain layer使domain layer更健壮 - 它不依赖于存储库的实际实现persistence layer，而仅依赖于存储库接口。

这意味着我们有：

现在，怎么样Person？

在anemic-domain-model我们可以有：

为什么要把 Person 放在持久层？
因为它包含特定于实现的代码。
例如，它可能包含与 JPA 相关的注释，并且与存储库相同，我们不希望在我们的域层中实现数据存储特定的实现。

我们可以使用anemic-domain-model来完成上述操作，因为 Person 不包含任何域逻辑，这意味着我们可以将 Person 放在持久层中。
在贫血域模型中，数据与行为是分离的，因此 Person 的行为是由分离的服务完成的，而不是写在 Person 本身中。

我们不能使用rich-domain-model进行这种层分离，因为在这种情况下， Person 确实包含特定于域的逻辑。

您将如何在富域模型应用程序中进行这种层分离？
或者，也许您认为不需要它。