jps*_*ook 6 c# architecture asp.net domain-driven-design repository-pattern
首先,我使用没有任何ORM框架的Web表单.
我一直在努力如何使我的域对象"智能"和"丰富",因为它们可以在不允许他们访问我的服务和存储库层的情况下.我最近的尝试是为在线商店创建礼券模型.
我看到的主要反复出现的问题是:
越来越多的逻辑不断引入服务层.对存储库的所有调用必须通过服务层并且每次验证参数时(例如 - 存在于db等中).结果,我的服务层正在增长,但我的域对象只有一些简单的合同验证.甚至对象验证也在服务层中,因为如果项的ID为null,它将检查db以确保代码是唯一的.IHMO,系统的消费者不应该关心他们需要的功能是否处理持久性.
我有一个单独的POCO用于兑换礼券时的交易日志条目.我假设我应该将这些交易的清单或集合作为我的礼券模型的属性,但我仍然不确定何时应该填写该属性.我是否在服务上添加了一个单独的方法,用于将事务加载到按需对象(例如 - LoadTransactions(gc object)),或者是否应在请求现有礼品证书或礼品证书列表时自动加载事务(或者getGCs中的一个选项,用于加载事务)
那些像"可用余额"这样的计算字段......我应该在我的对象上拥有这样的属性吗？无论何时我使用该对象,我都需要不断更新该属性以确保它是最新的.现在我只有一个服务方法GetBalanceByCode(gc代码).
即使是像兑换礼券的行动基本上是100%的数据中心(需要一定的输入参数,验证并添加事务日志条目DB).
服务层不断引入越来越多的逻辑（...）甚至对象验证也在服务层中（...）
验证并不是域模型元素的最佳候选。输入（我个人的偏好是它表示为命令）应该在应用程序服务级别进行验证。领域逻辑应该对业务的工作方式进行建模，并假设所有参数都是有效的。例如，域逻辑的良好候选者是计算：您希望将它们放在一个位置并对其进行良好的测试。
我有一个单独的 POCO，用于保存兑换礼券时的交易日志条目。
这种对象称为事件。您可以从 Eric Evans 的“自蓝皮书以来我学到的东西”演示中了解事件。事件基本上是一个不可变的实体。事件通常是单独聚合的，因为通常事件数量很多。通过使它们聚合，将它们作为其他对象集合的一部分延迟加载时不会有任何问题。
诸如“可用余额”之类的计算字段怎么样……我是否应该在我的对象上拥有这样的属性？
计算属性是一种自然适合域模型的逻辑，但是，更好的方法是每次计算值还是在对象更改时计算值并将其保留在数据库中，这是有争议的。
即使像兑换礼品券这样的操作基本上也是 100% 以数据为中心的（获取一些输入参数，验证它们并向数据库添加事务日志条目）。
此操作将被建模为创建CertificateRedeemed 事件。此事件可能由证书聚合或其他一些对象创建。Udi Dahan 的这篇博文可能会有所帮助
| 归档时间： |
|
| 查看次数： |
1329 次 |
| 最近记录： |