到那里领域驱动的开发专家......
我正在努力真正掌握DDD的概念。到目前为止,我一直在设计我的模型是数据驱动而不是域驱动。我已经阅读了几篇关于DDD的文章,看起来非常有趣,特别是对于大型应用程序。所以我试图定制我的模型来做到这一点。
我说过一个客户实体暴露了FreezeAccounts方法,该方法会禁用所有客户帐户。此方法与数据访问无关(基于持久性无知规则)。它会更新每个客户帐户(按需加载)的标志,并将更改保存到数据库。基于这个型号,这是正确的吗?我已经读过,在DDD中,每个表实体不一定只有一个类。这个功能应该在一个单独的类中吗?以下是一些示例代码:
public class Customer : ICustomer, ICustomerAction
{
#region Initialization
public Customer()
{
}
internal Customer(ICustomer view)
{
this.CustomerId = view.CustomerId;
this.Name = view.Name;
this.Email = view.Email;
this.IsActive = view.IsActive;
}
#endregion
#region Instances
private AccountCollection _accounts;
#endregion
#region Properties
#region ICustomer
public int CustomerId { get; private set; }
public string Name { get; set; }
public string Email { get; set; }
#endregion
#region Derived
public AccountCollection Accounts
{
get
{
if (_accounts == null)
_accounts = Account.GetListByCustomerId(CustomerId);
return _accounts;
}
}
#endregion
#endregion
#region Methods
#region CRUD
// Data Access Object accepts interface ICustomer
internal void Update()
{
CustomerDb.Update(this);
}
#endregion
#region ICustomerAction
// Exposed business Persistence Ignorance action
internal void FreezeAccounts()
{
foreach (Account account in this.Accounts)
{
account.IsEnabled = false;
account.Update();
}
}
#endregion
#endregion
}
答案 0 :(得分:2)
首先,在 DDD 和其他架构一样,数据访问层必须与域和业务逻辑分开,因此没有CRUD操作进入实体
所以要回答,是的,创建一个单独的层(不仅仅是一个类)来读取/写入存储上的数据,特别是在DDD中,您可以使用Martin的Repository和Unit Of Work模式福勒。
如果您想要DDD的示例,请查看here。
注意:我将在NuGet上发布我的DDD架构“视图”的新版本。
答案 1 :(得分:-1)
使用DDD,您希望清楚地了解什么是实体(具有唯一ID,并作为单个单元保留),什么是实体根(您希望向外界公开的实体),什么是服务(管理实体之间交互的代码)。
如何在DB中持久保存项目可能与其实体对象完全不同 - 但由于您只处理实体,因此外部世界不必担心这一点,并将其抽象为DAL。
在你的例子中,你正在充分利用对接口的编程(我在SOLID中),这很好,但是如果不知道系统的意图,很难说这个样本是否遵循DDD。 / p>