一起探讨领域驱动设计——架构与建模
领域驱动设计，挺好的，新做的一个商城也是基于这个思想来进行开发的。由此，想和大家一起分享一下应用这个思想在做项目中的一些领悟与经验，正好也能和大家一块探讨DDD，使我们能更好地理解领域驱动设计。
这一篇就和大家分享一下我使用的一些用于架构与建模使用的组件。
在这里，个人推荐使用一个开源的DDD框架组件：SharpArch.dll
这里是它的官方网站：http://www.sharparchitecture.net/
大家可以下载完整包，里面的组件基本上包括了后面项目所要用到的一些开源组件。
下面就举一个简单的例子与大家一起分享。
一。业务流程
会员之间的金额转账。
二。建模
在DDD中，实体（Entity)，即通过一系列连续性（continuity）和标识（identity ID）来定义 ，每个实体必须拥有自己的唯一ID，主键，如果没有一个ID标识，为每个实例加上一个具有唯一性ID，可能是内部使用。因此，对于每个实体来讲，都有一个自己的唯一标识ID。
因此，在使用了开源组件SharpArch.dll后，我们的领域模型都会继承于该组件中的Entity类型。
先上整体类图：
模型代码：
/// <summary>
/// 会员基本信息
/// </summary>
public class Member :Entity
{
/// <summary>
/// 会员用户名
/// </summary>
public virtual string MemberName { get; set; }
/// <summary>
/// 会员登录密码
/// </summary>
public virtual string Password { get; set; }
/// <summary>
/// 会员可用金额
/// </summary>
public virtual decimal SafeMoney { get; set; }
/// <summary>
/// 会员转账转出日志
/// </summary>
public virtual IList<MemberMoneyTransLog> SendMoneyTransLogs { get; set; }
/// <summary>
/// 会员转账转入日志
/// </summary>
public virtual IList<MemberMoneyTransLog> ReceiveMoneyTransLogs { get; set; }
public Member()
{
this.SendMoneyTransLogs = new List<MemberMoneyTransLog>();
this.ReceiveMoneyTransLogs = new List<MemberMoneyTransLog>();
}
}
/// <summary>
/// 会员金额转账日志
/// </summary>
public class MemberMoneyTransLog :Entity
{
/// <summary>
/// 转出会员
/// </summary>
public virtual Member SendUser { get; set; }
/// <summary>
/// 转入会员
/// </summary>
public virtual Member ReceiveUser { get; set; }
/// <summary>
/// 转账金额
/// </summary>
public virtual decimal TransMoney { get; set; }
/// <summary>
/// 转账时间
/// </summary>
public virtual DateTime TransTime { get; set; }
}
此时，大家可能会纳闷，上面说的实体必须有唯一ID，而现在这2个实体定义中，并没有ID啊，这样的模型会不会有问题呢？？
不用急，让我们一起来解开他们的基类Entity类：
原来，Entity类已存在Id属性，其类型为INT，这个时候有的铜子可能会说，实体所对应的主键不一定是INT型呀，有可能是自定义规则的字符串或者是Guid，不急不急，人家老外的东东不会那么2。我们仔细查看Entity时，发现其父类为EntityWithTypedId<int>。。。这里大家可能就知道应该怎么做了吧。。。
想用string型的，那就将模型继承于EntityWithTypedId<string>；想用Guid，那么就继承EntityWithTypedId<Guid>。
OK，回到现有的2个模型中，实体唯一ID被分离了。这样，至少从代码上来说，DDD的思想实现了，在实体中，唯一ID没有什么用途，仅作为一个标识。
三。业务逻辑的实现
回到DDD中，DDD的好处是什么，是什么，是什么，没错，是业务逻辑高内聚。内聚到哪里呢？？没错，就是内聚在模型中（充血啊，充血啊）！！个人认为那种贫血模型和传统的三层没有什么两样。。。
回到代码中，我们要实现一个会员的转账，就是把会员A的钱转到会员B的口袋中，顺带加个转账日志。。
实现如下：
/// <summary>
/// 会员基本信息
/// </summary>
public class Member : Entity
{
// 属性略了..
public Member()
{
this.SendMoneyTransLogs = new List<MemberMoneyTransLog>();
this.ReceiveMoneyTransLogs = new List<MemberMoneyTransLog>();
}
/// <summary>
/// 会员转账
/// </summary>
/// <param name="recieveMember">收钱的</param>
/// <param name="transMoney">转多少钱</param>
public virtual void TransMoney(Member recieveMember, decimal transMoney)
{
// 校验下你的钱够不
if (this.SafeMoney < transMoney)
throw new Exception("你个货,没那么多还想转账啊!");
// 我口袋的钱放血
this.SafeMoney -= transMoney;
// 收钱的人收钱
recieveMember.SafeMoney += transMoney;
// 来个日志
var transLog = new MemberMoneyTransLog
{
ReceiveUser = recieveMember,
SendUser = this,
TransMoney = transMoney,
TransTime = DateTime.Now
};
// 我的转出日志里面加条记录
this.SendMoneyTransLogs.Add(transLog);
}
}
好了，给Member模型加了针“会员转账”的血了，有的哥们又会问了，这样打鸡血的好处是？？
好吧，被你凹凸曼的造型打败了，回到传统BLL + DAL的三层构架中，我们是怎么实现的呢：
- 建个BllMember业务逻辑类；
- 加个方法TransMoney，使用三个DAL方法：给转账的人减钱，给接收的人加钱，再写条转账日志；
嗯嗯，差不多了，OK了，再回头看看代码。OMG，事务，事务！！得套个事务！嗯，加个事务的代码。。
好了，实现了，看代码，业务逻辑在哪里，业务逻辑体现了么，BLL中夹杂着大量的DAL与事务（可能还有LOG4NET的日志记录）代码。 这些代码与业务逻辑有关系么？没有任何关系，这些代码只是数据持久化的体现。。。回头再看看DDD中的实现，是不是觉得神精气爽？？
到了这里，各位朋友可能会有不少疑问：
- 实体的属性与方法为什么是虚(virtual )的呢？（好吧，你猜到了，数据持久化用的是NHibernate）
- 实体的数据持久化是怎样的呢？
- 业务逻辑实现了，我们的在UI层需要怎么调用呢？
- “会员转账”的方法中，并没有事务呀，事务是怎么实现的呢？
呵呵，由于时间的关系，老婆要我交差了，诸位请听下回分解。。