所以,我决定学习 DDD,因为它似乎可以解决我一直面临的一些架构问题。虽然有很多视频和示例博客,但我还没有遇到可以指导我解决以下场景的视频和示例博客:
假设我有实体
public class EventOrganizer : IEntity
{
public Guid Id { get; }
public string Name { get; }
public PhoneNumber PrimaryPhone { get; }
public PhoneNumber AlternatePhone { get; private set; }
public Email Email { get; private set; }
public EventOrganizer(string name, PhoneNumber primaryPhoneNr)
{
#region validations
if (primaryPhoneNr == null) throw new ArgumentNullException(nameof(primaryPhoneNr));
//validates minimum length, nullity and special characters
Validator.AsPersonName(name);
#endregion
Id = new Guid();
Name = name;
PrimaryPhone = primaryPhoneNr;
}
}
我的问题是:假设这将被转换并馈送到 MVC 视图,并且用户想要更新 AlternatePhone、电子邮件和许多其他属性,这些属性对于给定的有界上下文存在于该实体中(为简洁起见,未显示) )
我知道正确的指导是为每个操作都有一个方法,但是(而且我知道它有点反模式)我忍不住想知道这是否最终会触发数据库上的多个更新调用。
这是怎么处理的?在接下来的某个地方,是否会有一些东西将我的 EventOrganizer 映射到某些东西 - 比如 DbEventOrganizer 并收集对域实体所做的所有更改并一次性应用这些更改?
DDD 更适合基于任务的 UI。你所描述的非常面向CRUD。在您的情况下,各个属性被视为独立的数据字段,其中一个或多个属性可以通过单个通用业务操作(更新)进行更新。
如果您想成功使用 DDD,则必须对您的领域进行更深入的分析。
为什么有人会一起更新所有这些字段?用户试图通过这样做来实现什么隐式业务操作?有没有更具体的业务流程,通过改变来表达PrimaryPhone
, AlternatePhone
and Email
一起?
也许这正在改变ContactInformation
of an EventOrganizer
?如果是这种情况,那么您可以建模一个ChangeContactInformation
操作于EventOrganizer
。然后你的 UI 会发送一个ChangeContactInformation
命令而不是update
命令。
至于聚合根 (AR) 的持久性,如果您使用的是 RDBMS,则通常由像 NHibernate 这样的 ORM 来处理。但是,还有其他方法可以持久保存 AR,例如事件源、NoSQL DB,甚至存储 JSON https://vaughnvernon.co/?p=942或 RDBMS 中的任何其他数据交换格式。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)