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

以前做了个简单的论坛但是之前的版本都没有考虑过架构设计。所以想在第三个版本中应用分层架构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 ServiceDomain EntityDomain EventEvent Bus四个元素。不需要其他任何概念。 需要特别指出的是 1所有的Entity是独立的相互平等的没有什么聚合Aggregate的概念也就没有Aggregate Root的概念。所有的Entity之间的交互应该总是通过Event来完成。而不应该通过对象引用的方式来达到相互协作的目的。以前大家都以为面向对象编程就一定要让对象之间相互引用。大家想想为什么我们要让对象之间相互引用目的很简单就是能让对象相互影响相互协作。那难道就没有其他方法可以达到此目的吗当然不是我们可以用事件也就是用通知和响应的方式。我认为对象引用或者说调用其他对象的方法是造成对象之间耦合的根本原因。而用发送事件和响应事件的方式才是真正体现事物交互的本质联系比如我们人类如果我狠狠的掐你一下你可能会疼的跳起来可能嘴巴还会撅起来。真个过程可以描述为皮肤接受到外界刺激传递到大脑大脑作出反应当然有时可能是条件反射通知肌体其他部位作出相应反应跳起来撅嘴巴。另外任何一个Entity都具有发送事件和处理其关心的事件的能力所有的业务逻辑验证都应该在Entity中实现如果一个Entity不能实现的验证则会通过发送消息让多个Entity协作完成验证。 2领域服务应该非常的薄它只需要做一件事情那就是发送事件给事件处理器仅此而已它相当于一个圆球的表明而里面包含的各个相互作用的实体。就如同人类的皮肤一样人的皮肤也很薄。这点和经典的领域驱动设计中的领域服务也完全不相同。经典的领域驱动设计中的领域服务的职责是处理那些需要多个实体合起来才能完成的事情比如银行转账。 3中央事件处理器其功能应该和人类的大脑一样应该很聪明它应该知道任何一个事件该怎么处理。也就是说它会知道该通知哪些实体去完成所有的响应操作。这个功能类似于事件驱动架构Event Driven ArchitectureEDA中的Event Bus。 4整个领域层应该是持久化透明的也就是说不需要关心Entity的修改是如何被持久化到数据库的。所有的对象只需要关心自己的感兴趣的事件并处理之修改自己的状态。仅此而已。 基础层Infrastructure Layer 和我们平时常说的基础层类似包含一些抽象的接口或底