领域驱动设计及分层

•需求：软件的价值-领域部分，和技术无关

•设计：减少成本

•领域建模：贯通需求和设计，突出领域模型，让领域的复杂度和代码的复杂度相匹配

•抽象：并不是象现实世界，而是对现实世界中根据我们要解决的问题进行的抽象建模，比如房子根据我们关注点不同可以抽象成门窗户等构成，但也可以抽象成水泥，钢筋等构成的。

界面层

应用逻辑层

领域层(实体，值对象，服务)

基础设施层

是允许再加层的，比如要向其它系统提供远程服务。可以在应用逻辑上层，加入一个门面或外观，然后再加一层WebService层。如果改天改用ICE直接再在外观上层加个ICE层就好。

领域逻辑的实现：

比如我们的公司，我们每个人是个实体，我们不仅仅有属性，更重要的我们还是在做事情的，比如编码。所以实体一个很大的功能就是要有服务，但有些服务需要几个实体协作来完成，这时放在哪个实体里都水太合适，这时就做成服务。

基础设施层的repository:可以理解为如果我们到银行办个业务，就要有相应的业务实体来为我们服务，repository就是为我们寻找服务实体的导航员。但记住我们只能找到聚合的根，比如我要借一个人的钱，那我不能直接和他的钱打叫道，要先给钱的主人（聚合根）打交道。

领域逻辑的实现方法：按Martin Folwler的分法，分为事务脚本，表模块和领域模型。

 

大家用的比较多的其它分层

Action

Service

Dao

Model

 

评：应该是最常用的一个了，很方便时行项目管理。一般model层会做成vo(值对象)，业务全由服务层来做。还有一个小变种，就是把service再划分为应用服务和领域服务。

       还有一种情况是为事务再加入一层，现在都是声明式事务了，可以做到业务逻辑和具体的数据库代码解耦，已经不再需要。