.NET逻辑分层架构演示:DDD分层架构的进化

概述:

 

如果在架构层次上设计有缺陷,搭建的解决方案不是牵强就是让人无法理解。如果搭建的解决方案依赖即不能和架构图匹配又引入了过多的依赖关系,这样的解决方案应用DDD就很难。

架构是高层的设计,如果设计和理解有误,必将在实现时带来各种问题。架构又是最稳定的,不会因为各种具体技术的依赖,如各种UI框架、ORM框架、IoC框架的更新换代而受到影响。上文的总结没有任何Demo是因为架构更偏向于设计层面,有从设计视图创建解决方案经验的人,一看就知道我在说什么。本文将展示从架构设计视图到.NET多项目解决方案的过程。主要包含以下内容:

(1)演示DDD分层架构到.NET多项目解决方案的映射。

(2)演示DDD分层依赖到.NET项目引用的映射。

(3)演示依赖注入在.NET多项目解决方案中的使用。

本文出自:http://www.cnblogs.com/easygame/

一、原始的DDD分层

 

1.架构图

2.搭建解决方案

新建空白解决方案,添加如下项目:

(1)DDD.Domain类库项目。

(2)DDD.Application类库项目。

(3)DDD.Infrastructure类库项目。

(4)DDD.UI.MVC ASP.NET 空项目,选中MVC引用。

(5)DDD.Repository类库项目。

3.设置项目间的引用关系:

(1)DDD.UI.MVC添加DDD.Application、DDD.Domain、DDD.Infrastructure和DDD.Repository的引用。

(2)向DDD.Application添加DDD.Domain、DDD.Infrastructure引用。

(3)向DDD.Domain添加DDD.Infrastructure引用。

(4)向Repository项目添加DDD.Domain和DDD.Infrastructure引用。

4.使用依赖注入:

为了更彻底的解耦,我们即使对依赖注入的实现也应用依赖倒置原则,我们不依赖任何具体的IoC框架及其种类和版本。在基础设施层中使用2种不同的IoC框架实现了该接口,并且在使用时展示了通过直接注入和通过反射两种方式。通过反射可以将IoC的实现依赖使用配置文件管理。

(1)IoC抽象接口

(2)管理类

(3)管理依赖注入

5.代码图和解决方案视图:

代码图赤裸裸的告诉我们三个字“不和谐”:

(1)看起来更像以基础设施层为核心。

(2)Repository无法置于基础设施层,即使你将它的命名空间改为DDD.Infrastructure.Repository也没有用。

(3)领域层对外有依赖。

(4)看了架构图谁能跟这代码图对应上?

Demo1下载:点击下载

二、改善的DDD分层

 

1.架构图

2.搭建解决方案

新建空白解决方案,添加如下项目:

(1)DDD.Domain类库项目。

(2)DDD.Application类库项目。

(3)DDD.Infrastructure类库项目。

(4)DDD.UI.MVC ASP.NET 空项目,选中MVC引用。

3.设置项目间的引用关系:

(1)DDD.UI.MVC添加DDD.Application、DDD.Domain和DDD.Infrastructure的引用。

(2)向DDD.Application添加DDD.Domain、DDD.Infrastructure引用。

(3)向DDD.Infrastructure添加DDD.Domain引用。

4.改善:

(1)IEntity和IRepository接口定义在领域层,领域层不再依赖基础设施层。

(2)Repository真正在基础设施层实现。

5.代码图和解决方案视图:

看起来很不错:

(1)和架构图完美对应。

(2)领域层为中心。

(3)再也不用为基础设施层无法引用领域层而在服务层添加不必要的代码了。

Demo2下载:点击下载

三、最新的DDD分层

1.架构图

2.搭建解决方案:同上

 

3.设置项目间的引用关系:

(1)DDD.UI.MVC添加DDD.Application、DDD.Domain和DDD.Infrastructure的引用。

(2)向DDD.Application添加DDD.Domain引用。

(3)向DDD.Infrastructure添加DDD.Application和DDD.Domain引用。

4.改进:

(1)将IService接口定义在应用层。

(2)进一步将所有依赖的接口定义在领域层和应用层,包括依赖注入管理。

5.代码图和解决方案视图:

更好理解和使用:

(1)在架构级别,以领域为核心,将其他技术依赖抹平到一个实现层次,写代码再也不用担心不知道往哪写了。

(2)将领域逻辑和应用逻辑扔到应用层和领域层,所有依赖扔到实现层,架构图就是解决方案视图。

(3)在三种解决方案中,依赖最少,依赖方向一致,最易理解和使用。

 

Demo3下载:点击下载

参考

1.Patterns of Enterprise Application Architecture 【企业应用架构模式】

2.Domain-Driven Design 【领域驱动设计:软件核心复杂性应对之道】

3.Applying Domain-Driven Design and Patterns【领域驱动设计与模式实战】

4.Implementing Domain-Driven Design 【实现领域驱动设计】

5.Microsoft Application Architecture Guide 【微软应用架构指南(第2版)】

6.Professional Enterprise .NET 【精通.NET企业项目开发:最新的模式、工具与方法】

7.Professional ASP.NET Design Patterns 【ASP.NET设计模式】

时间: 2024-11-09 00:02:07

.NET逻辑分层架构演示:DDD分层架构的进化的相关文章

4、传统三层架构与DDD分层架构

4.传统三层架构与DDD分层架构 模型是抽象的 现实是形象的 技巧是重要的 思想是永恒的 从传统三层架构与DDD分层架构的编程演变其实是思想的演变. 传统三层架构,即用户界面层UI.业务逻辑层BAL.数据访问层DAL.一般同时还有建立一个Model实体类的工程项目.DDD分层架构,即表现层UI.应用层Application.领域驱动层Doman.基础设施层Infrastructure. 传统三层架构,我一直使用.结构单一.逻辑也清晰,三层各处理各自的事务,上层向下层引用接口与方法,下层向上层提供

应用程序框架实战十三:DDD分层架构之我见(转)

前面介绍了应用程序框架的一个重要组成部分——公共操作类,并提供了一个数据类型转换公共操作类作为示例进行演示.下面准备介绍应用程序框架的另一个重要组成部分,即体系架构支持.你不一定要使用DDD这样的架构,使用单层架构和普通三层架构一样可以,不过你如果希望获得更进一步的复用性和封装度,使用更加面向对象的技术是必经之程. 我在2010年以前还在使用古老的ASP.NET WebForm和原始的Ado.Net.之前我有个观念:.NET技术发展太快,跟着微软屁股后面跑太累,所以只使用它一些原始的东西,自己封

应用程序框架实战十三:DDD分层架构之我见

前面介绍了应用程序框架的一个重要组成部分——公共操作类,并提供了一个数据类型转换公共操作类作为示例进行演示.下面准备介绍应用程序框架的另一个重要组成部分,即体系架构支持.你不一定要使用DDD这样的架构,使用单层架构和普通三层架构一样可以,不过你如果希望获得更进一步的复用性和封装度,使用更加面向对象的技术是必经之程. 我在2010年以前还在使用古老的ASP.NET WebForm和原始的Ado.Net.之前我有个观念:.NET技术发展太快,跟着微软屁股后面跑太累,所以只使用它一些原始的东西,自己封

应用程序框架实战十五:DDD分层架构之领域实体(验证篇)

在应用程序框架实战十四:DDD分层架构之领域实体(基础篇)一文中,我介绍了领域实体的基础,包括标识.相等性比较.输出实体状态等.本文将介绍领域实体的一个核心内容——验证,它是应用程序健壮性的基石.为了完成领域实体的验证,我们在前面已经准备好了验证公共操作类和异常公共操作类. .Net提供的DataAnnotations验证方法非常强大,Mvc会自动将DataAnnotations特性转换为客户端Js验证,从而提升了用户体验.但是客户端验证是靠不住的,因为很容易绕开界面向服务端提交数据,所以服务端

应用程序框架实战十四:DDD分层架构之领域实体(基础篇)

上一篇,我介绍了自己在DDD分层架构方面的一些感想,本文开始介绍领域层的实体,代码主要参考自<领域驱动设计C#2008实现>,另外参考了网上找到的一些示例代码. 什么是实体 由标识来区分的对象称为实体. 实体的定义隐藏了几个信息: 两个实体对象,只要它们的标识属性值相等,哪怕标识属性以外的所有属性值都不相等,这两个对象也认为是同一个实体,这意味着两个对象是同一实体在其生命周期内的不同阶段. 为了能正确区分实体,标识必须唯一. 实体的标识属性值是不可变的,标识属性以外的属性值是可变的.如果标识值

应用程序框架实战十八:DDD分层架构之聚合

前面已经介绍了DDD分层架构的实体和值对象,本文将介绍聚合以及与其高度相关的并发主题. 我在之前已经说过,初学者第一步需要将业务逻辑尽量放到实体或值对象中,给实体“充血”,这样可以让业务逻辑高度内聚,并为你提供业务逻辑的唯一访问点.而聚合则是第二步,它将多个相关业务概念包装到单一的概念中,从而大幅简化系统设计,由于受传统数据建模思维影响,我在聚合方面吃过大亏,花了将近一年才真正用起来,为了你少走弯路,我会把一些要点总结出来供你参考. 什么是聚合? 聚合包装一组高度相关的对象,作为一个数据修改的单

领域驱动设计(DDD)分层架构的三种模式

模式一:四层架构 1.User Interface为用户界面层(或表示层),负责向用户显示信息和解释用户命令.这里指的用户可以是另一个计算机系统,不一定是使用用户界面的人.2.Application为应用层,定义软件要完成的任务,并且指挥表达领域概念的对象来解决问题.这一层所负责的工作对业务来说意义重大,也是与其它系统的应用层进行交互的必要渠道.应用层要尽量简单,不包含业务规则或者知识,而只为下一层中的领域对象协调任务,分配工作,使它们互相协作.它没有反映业务情况的状态,但是却可以具有另外一种状

应用程序框架实战十六:DDD分层架构之值对象(介绍篇)

前面介绍了DDD分层架构的实体,并完成了实体层超类型的开发,同时提供了验证方面的支持.本篇将介绍另一个重要的构造块——值对象,它是聚合中的主要成分. 如果说你已经在使用DDD分层架构,但你却从来没有使用过值对象,这毫不奇怪,因为多年来养成的数据建模思维已经牢牢把你禁锢,以致于你在使用面向对象方式进行开发时,还是以数据为中心. 当我们完成了基本的需求分析以后,如果说需要进行设计,那么你能想到的就是数据库表及表关系的设计,这就是数据建模.数据建模的主要依据是数据库范式设计,根据要求严格程度的递增分为

应用程序框架实战十七:DDD分层架构之值对象(层超类型篇)

上一篇介绍了值对象的基本概念,得到了一些朋友的支持,另外也有一些朋友提出了不同意见.这其实是很自然的事情,设计本来就充满了各种可能性,没有绝对正确的做法,只有更好的实践.但是设计与实践的好与坏,对于不同的人,以及处于不同的环境都有不同的诠释,这是一个仁者见仁,智者见智的问题.DDD非常抽象,以至于它的每一个概念,对于不同的人都有不同的看法,更何况基于DDD的.Net实践,就更难分辨哪一个用法更标准.更正宗. 我对DDD的认识虽然还很肤浅,用得也很山寨,但这可能更加适合初步接触DDD的朋友.还是那