系统架构师谈企业应用架构之业务逻辑层

public class Order  
{  
private int _orderID;  
public Order(int orderID)  
{  
_orderID = orderID;  
}  
public int OrderID  
{  
get 
{  
return this._orderID;  
}  
set 
{  
this._orderID = value;  
}  
}  
private int _orderState;  
public int OrderState  
{  
get 
{  
return this._orderState;  
}  
set 
{  
this._orderState = value;  
}  
}  
private UserInfo _userinfo;  
public UserInfo User  
{  
get 
{  
return this._userinfo;  
}  
set 
{  
this._userinfo=value;  
}  
}  
　} 

上面我们看到了活动记录模式的简单使用方式，当然我这里没有说是写出来可以运行的实例代码。只是简单的显示了，使用这些模式可能的用法，当然如果大家有更好的理解或者用法可以一起交流。当然活动记录模型一般就能满足我们的系统功能，如果说针对业务复杂的领域，那么必须设计领域模型去完成相应的业务逻辑层的设计。下面我们将来介绍领域模型模式的相关实例。

2、领域模型模式

我们前面讲解的几类模式，其实说白了都是以数据为中心进行抽象与设计的形式，当然采用这样的形式无疑是以业务中的数据为中心，并不是关心的业务本身。以数据为核心的设计方法一般流程如下：

498)this.width=498;'' onmousewheel = ''javascript:return big(this)'' alt="" src="/uploadfile/201301/12/06122036747.png" />

一般来说我们目前主流的方式都是这样的顺序来执行。当然通过这样的方式的确一般的简单应用当然都是没有太大的问题。有的时候我们需要同时关系对象的数据与行为，那么显然以数据为核心的情况就会显得力不从心，当然简单的系统时不会有太大的体现，当时当系统的规模上升到一定的程度时，哪怕添加一些新的需求时，对系统的影响都是致命的。

领域模型关注的是系统期待的行为及系统正常工作所需要的数据流。一般我们在设计领域模型的时候需要这个领域的专家协助，最后以类的形式呈现出来。当然

领域模型模式中的实现方式，大家都知道的就是有名的DDD(领域驱动设计)。

领域模型设计的最终目标就是与系统的概念模型匹配起来。我们可以把领域模型看作是概念模型的物理模型。在一个项目中可以说领域模型是最重要的，最关键的部分。

领域模型可以看作是一系列对象之间的交互。领域模型中的每一部分都需要用一个带有行为的类来表示。这个怎么理解呢，请看图：

498)this.width=498;'' onmousewheel = ''javascript:return big(this)'' alt="" src="/uploadfile/201301/12/3F122036692.png" />

订单信息对象首先会与订单中的产品对象有交互关系，产品项与产品分类有交互关系。订单信息与用户买家有交互关系，订单的其他信息(物流信息、支付信息等)有交互关系。

例如我们常说的记录的系统日志，不管是错误日志还是其他的所有系统中的日志，那么我们建议的方式采用AOP的方式来处理。那么我们来看看具体的代码实现：

//定义接口  
public interface ILog  
{  
//具体的写日志的方法  
void WriteLog();  
}  
//简单实现  
public class BaseWrite : ILog  
{  
#region ILog 成员  
/// <summary>  
/// 基本的书写日志的方法  
/// </summary>  
public void WriteLog()  
{  
try 
{  
Write.WriteLog(this);  
}  
catch 
{  
}  
}  
#endregion  
} 

具