领域驱动设计的实践经验分享之分层架构.docVIP

以前做了个简单的论坛但是之前的版本都没有考虑过架构设计。所以想在第三个版本中应用分层架构DDDEDA架构重新设计一下我的论坛。经过半年的努力终于整出了一个让自己比较满意的架构了但是也仅仅是一个Demo还不能真正使用但对于说明架构设计已经足矣。源代码下载地址/netfocus/ProductName.rar 由于本人接触领域驱动设计的时间还很短对于如何设计领域对象还没有丰富的经验。所以我希望大家看了我的源代码中的领域层中的领域对象后不要笑话我呵呵。因为我本文主要想向大家展示的是我对分层架构的思考和自己的想法我想大家自己的想法才是最重要的吧我本人也很注重思想、思考不要老是讨论别人的老外的架构有多好多好我们要有自己的思想。所以大家在看我文章和源代码时不能过分专注于一点上而应该从总体上来看待。 开发工具Visual Studio 2010 项目结构图 说明 1关于项目的命名规则。假设现在有一个公司要做一个项目我觉得比较好的项目命名方式为以CompanyName.ProductName作为前缀基础类库命名为Common产品中的某个子应用模块则可以命名为CompanyName.ProductName.Modules.ForumCompanyName.ProductName.Modules.Blog等。然后每个模块还可以根据模块的分层设计分出不同的Project比如论坛的应用层可以命名为CompanyName.ProductName.Modules.Forum.ApplicationService等。由于我做的只是一个展示架构的Demo所以没有用具体的CompanyNameProductName。我觉得在开发阶段我们可以不使用最后的名字到了最后项目快完成时再做统一全局替换即可。 2架构设计介绍。 一个经典的基于领域驱动设计Domain Driven Design 的应用分为下面的层次 我的项目也同样采用上面的分层架构对于上面每一层的功能和职责我想大家应该都比较清楚了。我主要想和大家分享一下基于这样的分层架构下我的实现方式 先来看一下各个层中包含的主要元素。 说明 界面层User Interface or Presentation Layer没有什么特别的因为我是采用ASP.NET MVC来最为界面层所以会包含Page、Control、Controller、View ObjectVO。前三个大家都很熟了至于View Object相当于Page或Control的Model负责提供数据给界面以及保存界面录入的数据。View Object还有一个很重要的功能就是会对界面提交的数据做简单的数据有效性验证但不会包含任何的业务逻辑验证。任何业务逻辑验证会由领域层来完成。界面层只会和应用层或基础层打交到不会和领域层有任何关系。界面层的任何查询或行为都通过应用层实现界面层通过构建应用层中的某个Request然后发送到应用层应用层完成相应操作或查询后返回一个Reply给界面层。如果是查询的操作则Reply中会包含一个或多个DTO界面层将DTO转换为VO然后显示。 应用层Application Layer真正意义上的非常薄的一层该层由一些应用服务来完成所有功能。为了性能方面的考虑在学习了命令查询职责分离Command Query Responsibility SeparationCQRS的思想后我觉得应该将查询和命令的实现分离这样可以对这两部分更好的进行单独设计。因此在我的实现中对于查询的Request会委托给一个专门负责查询的服务去完成对于命令的Request会委托给一个专门负责处理命令的领域服务去完成。另外只要是有命令处理的请求就会最终用事务的方式来提交所有的修改 领域层Domain Layer我设计的最具特色的一层。大家知道经典的领域驱动设计领域层会包含领域服务、实体、值对象、聚合根、工厂仓储这些概念。但是在我看了一些资料和自己独立思考后发现用这样的方式来组织领域逻辑在我看来不是太好因为1整个模型没有体现出事物的相互协作的特性也就是没有消息机制2用不太自然的方式来组织相互作用的各个实体比如Aggregate的概念在我看来就是一个不该有的概念。在真实的世界中我认为最好的软件就是我们自己那就是“人类”。想想看人类是亿万年才进化出来的地球上最高级的生物他的内部结构绝对是一个非常好的”软件“。大家都知道人有大脑、皮肤、细胞、神经元。如果把人和一个领域模型想比较那么人的皮肤相当于领域模型暴露给外面的Domain Service人的细胞相当于领域模型中的各个Domain Entity人的大脑相当于领域模型的一个”中央事件处理器“Event Bus人的神经元相当于领域模型中的各种消息Domain Event也就是说一个真正的符合客观实际的领域模型应该包含Domain S