阅读目录：
对软件开发方法论有兴趣的博友应该发现最近“领域驱动设计”慢慢的被人发现被人实践起来，园子里也慢慢有了DDD的学习气氛和宝贵实战经验的分享。其实之前我也痴迷于DDD，为什么会痴迷于它并不是因为它是所谓的新技术，也不是因为各种对它的炒作，而是我觉得我找到了能解放我们进行企业业务系统开发的方法论。
DDD可以很好的指导我们开发可靠的软件系统，尤其是现在的企业业务复杂多变的情况下，使用DDD可以很好的随着业务变化不断的重构现有的领域模型，最为重要的是我觉得DDD是能够很好的实施敏捷价值观的软件开发方法论。
如果你想重构、测试你所写的业务代码，少不了对代码进行适当的罗动，如果没有一个好的结构让你存放你所提取出来的代码是比较无奈的。包括现在敏捷软件开发方法论中最重要的TDD方法论更加的依赖代码的结构是否能够允许进行重构，如果你的结构是很死板的，扁平化的其实很难实施TDD，你会发现你所抽象出来的概念无耻容纳。
所以我认为DDD是为了解决上述这些问题的一个好的方法，当然前提是你自己实施过之后才有资格去评判它的优劣，而且是客观公正的。
实施DDD是很费时费力的工程，没有传统的开发方法那么简单快捷，而且对开发人员的整体要求有了一个新的标准，所以本篇文章将介绍一个可以用来替代DDD模式的另外一个比较好的企业模式“活动记录模式”。
领域模型模式其实就是领域驱动设计，两个是一个意思。有兴趣的朋友可以进一步学习领域驱动设计，我认为DDD对于一名企业应用开发人员来说是必不可少的一门设计思想，就好比设计模式一样，它也有着一套模式，用来指导我们进行相关业务场景的设计。
领域模型模式也称领域驱动设计，对业务模型进行等价的面向对象建模，无需太多考虑数据存储的技术细节，但是并不是说完全不考虑如何存储，如果谁告诉你说完全不需要考虑存储那是错误的，因为你要考虑这个领域模型最终是要如何持久化的，以免你将领域模型创建成一个巨大的蜘蛛网。说不需要考虑领域模型如何持久化其实是说你目前只需要把握领域模型创建，不去完成持久化设计细节而已，但是这两个工作往往是互相考虑的。
难道一个不懂得如何存储关系数据的人能够创建出能满足程序员很好的开发的模型吗。
活动记录模式是最靠近DDD的模式，它将数据库中的表中的一行作为自己的对象化字段，然后围绕着这些字段展开的业务逻辑，将数据字段与业务逻辑都封装在一个实例对象中。
活动记录模式与表模块模式不同的是，表模块模式是一个对象对应着一个数据库中的表，而活动记录模式是一个对象对应着一个行记录，所以称为活动记录模式。
此模式最大好处是可以基本上满足业务不是很复杂的情景下，我倒觉得活动记录模式在现在的面向SOA架构下能够更适合企业的业务系统开发团队。使用领域驱动太过于复杂，不使用又会面临着业务快速变化的困境，所以活动记录模式可以考虑试试。
我们来看一个简单的示例，了解活动记录模式的开发及要点。
活动记录模式是使用与数据库中的表结构一直的方式使用类的，也就是说表中的列就是类的字段，当然也可以在处理业务逻辑时的辅助字段，尽量不包含多余的字段，这样可以有效保证干净的活动记录。
namespace Business.RecordModels.OrderModel
{
using System;
using System.Collections.Generic;
/// <summary>
/// Order table fields.
/// </summary>
public partial class OrderFields
{
/// <summary>
/// Order id.
/// </summary>
public long OId { get; set; }
/// <summary>
/// Order name customer declare.
/// </summary>
public string OName { get; set; }
/// <summary>
/// Product ids.
/// </summary>
public List<long> PIds { get; set; }
/// <summary>
/// Order sum price.
/// </summary>
public float Price { get; set; }
/// <summary>
/// Order distribute status.
/// </summary>
public int DistributeStatus { get; set; }
/// <summary>
/// Order payment status.
/// </summary>
public int PaymentStatus { get; set; }
/// <summary>
/// Order signer.
/// </summary>
public string Signer { get; set; }
/// <summary>
/// Submit datetime.
/// </summary>
public DateTime SubmitDt { get; set; }
}
}
定义一个Order活动记录的字段类，也可以直接将该字段定义在Order类中，但是一般我喜欢独立出来，因为字段一旦多了看起来实在很累。如果你想将字段直接定义在Order类中我建议你使用部分类来处理，这样比较干净。
字段中的public List<long> PIds { get; set; } 商品ID集合字段是有意聚合到该字段类中的，因为不管是业务处理还是数据持久化都是需要相关连的业务字段的。 （活动记录模式不要求你很死板的一个表一个记录实例，只要你使用你自己的方式能够让代码结构看上去很自然就是很恰当的。）
虽然你直接使用了int类型来描述业务字段，不过你可以使用其他方式让来该字段在业务处理中不直接使用语言类型而是业务概念。
namespace Business.RecordModels.OrderModel
{
/// <summary>
/// Distribute status const.
/// </summary>
public class DistributeStatusConst
{
public const int NoDistribute = 1;
public const int BeginDistribute = 2;
public const int EndDistribute = 3;
}
}
配送状态常量类，定义明确的业务概念的值。namespace Business.RecordModels.OrderModel
{
/// <summary>
/// Payment status const.
/// </summary>
public class PaymentStatusConst
{
/// <summary>
/// No payment.
/// </summary>
public const int NoPayment = 1;
/// <summary>
/// End payment.
/// </summary>
public const int EndPayment = 1;
}
}
配送状态常量类，定义明确的业务概念的值。
对活动记录的创建我建议是用工厂来处理，毕竟这里面包含了很多业务逻辑在里面的。
namespace Business.RecordModels.OrderModel
{
using Common;
/// <summary>
/// Order class factory.
/// </summary>
public class OrderFactory
{
/// <summary>
/// Create a order instance.
/// </summary>
/// <param name="fields">Order fiels instance.</param>
/// <returns>Order instance.</returns>
public static Order CreateOrder(OrderFields fields)
{
if (fields.IsNull() || fields.OName.IsNullOrEmpty()
|| fields.PIds.IsNullOrEmpty() || fields.Price.IsLessThanOrEqual0()) return null;
fields.DistributeStatus = DistributeStatusConst.NoDistribute;//No distribute.
fields.PaymentStatus = PaymentStatusConst.NoPayment;//No payment.
return new Order(fields);
}
}
}
活动记录模式不等于没有DDD那么好，其实在业务相对不是非常复杂的情况下，活动记录模式还是相当不错的，简单快捷，对一些原子类型的字段处理使用常量就很不错。
这里我们使用DistributeStatusConst.NoDistribute、PaymentStatusConst.NoPayment 常量字段来明确的传达业务概念，而不是非要用枚举，经验告诉我有时候枚举没有常量方便。
活动记录对象中包含了该记录所表达的业务逻辑，这里的Order将包含该表所表达的业务逻辑处理。
namespace Business.RecordModels.OrderModel
{
using System;
/// <summary>
/// Order table record
/// </summary>
public partial class Order
{
/// <summary>
/// Order table columns.
/// </summary>
private OrderFields fields { get; set; }
/// <summary>
/// New a order instance only internal use.
/// </summary>
/// <param name="fields">Order fields.</param>
internal Order(OrderFields fields)
{
this.fields = fields;
}
/// <summary>
/// Calculate order expiration time.
/// </summary>
/// <returns>DateTime</returns>
public DateTime CalculateExpirationTime()
{
//Here you can use strategy.
if (this.fields.PaymentStatus == PaymentStatusConst.NoPayment)//No payment logic
{
return this.fields.SubmitDt.AddDays(1);
}
else if (this.fields.DistributeStatus == DistributeStatusConst.NoDistribute)//No payment logic
{
return this.fields.SubmitDt.AddDays(30);
}
return this.fields.SubmitDt.AddDays(3);
}
}
}
这里我有一个简单的计算当前订单到期时间的方法（CalculateExpirationTime），在方法内部有一些业务逻辑，而该业务逻辑和当前实例一起存在。
通过使用活动记录模式可以很好的将字段与业务方法有效的集合起来，这样会使得业务逻辑处理比较有条理性，也便于测试和重构。
这里需要强调的是活动记录模式是业务层和数据层共用的模式，当时这里我们所讲的是面向业务层的，也就是说你数据层可以使用任何方式来和活动记录模式整合，现在比较流行ORM了，如果你对性能有要求你可以使用手工处理，建议使用表入口模式来结合，因为数据层没有什么逻辑，如果你的数据层有相关的逻辑我像也不会出现最后的数据源上，而是应该在数据适配层上处理掉，如：缓存、填补字段等。
很难在一篇文章中说明所有问题，活动记录模式如果是用在读写分离大的架构中的写端时必须需要“工作单元”模式来协调多“记录”之间的事务性。但是如果你在查询端使用活动记录模式，那么大部分情况下是不需要事务性的，当然查询端我觉得使用事物脚本模式比较直观点，因为业务逻辑也不会有多少。
还是那句话，本篇文章只是分享点自己学习过程中和工作过程总结的经验，仅供参考。其实企业应用架构是一个看似简单其实很复杂的方向，希望与各位一起学习一同进步，谢谢。
作者：王清培
出处：http://blog.csdn.net/wangqingpei557
本文版权归作者和CSDN共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
原文：http://blog.csdn.net/wangqingpei557/article/details/38947247