请考虑以下示例:
例如:
OrderA必须有一个事务。
OrderB必须有两个事务。
OrderC可以有n个事务.
当我们更新订单的值时,需要根据算法-specific订单类型计算事务的值。
我们如何为这种情况设计一个模型?我们可以在aggregateRoot中使用继承还是应该使用组合?比如说?
/// <summary>
/// AggregateRoot
/// </summary>
public abstract class Order
{
protected ISet<Transaction> _transactions;
public IEnumerable<Transaction> Transactions
{
get { return _transactions; }
}
public abstract OrderType OrderType { get; }
public decimal? Value { get; protected set; }
public void SetValue(decimal? value)
{
Value = value;
UpdateReleatedTransaction();
}
protected abstract void UpdateReleatedTransaction();
}
public class OrderA : Order
{
public OrderA()
{
_transactions.Add(new Transaction(this));
}
public override OrderType OrderType
{
get { return OrderType.OrderTypeA; }
}
protected override void UpdateReleatedTransaction()
{
EnumerableExtensions.ForEach(_transactions, tran => { tran.SetValue(Value); });
}
}
public class OrderB : Order
{
public OrderB()
{
_transactions.Add(new Transaction(this)
{
Status = Status.Open
});
_transactions.Add(new Transaction(this)
{
Status = Status.Close
});
}
public override OrderType OrderType
{
get { return OrderType.OrderTypeB; }
}
protected override void UpdateReleatedTransaction()
{
EnumerableExtensions.ForEach(_transactions, tran =>
{
if (tran.Status == Status.Open)
tran.SetValue(Value);
if (tran.Status == Status.Close)
tran.SetValue(-1*Value);
});
}
}
发布于 2015-02-22 12:27:51
DDD Aggragate中的继承是一个棘手的话题。我认为大多数人(我也在“实现领域驱动设计”中读过这篇文章)会选择在AR中不继承。
要考虑的主要问题是行为。将来不同的订单类型会有不同的公共接口吗?如果答案是肯定的,那么您必须按照每个订单拥有不同的ARs (以及存储库)的路线。我知道你还没问过这个问题,但记住这一点很好:)。
以您的例子为例,IMHO使用组合没有多大价值,因为新的AR只是一个非常薄的订单包装器,除了委托之外,这个包装器没有任何其他的响应性。如果您保持代码整洁,重构它(创建封装订单的AR )应该非常容易。
免责声明:过去5年我一直在使用DDD,我仍然很难理解它.所以接受我的建议吧。
https://stackoverflow.com/questions/28657123
复制相似问题