一、引言
架构是高层的设计，如果设计和理解有误，必将在实现时带来各种问题。架构又是最稳定的，不会因为各种具体技术的依赖，如各种UI框架、ORM框架、IoC框架的更新换代而受到影响。上文的总结没有任何Demo是因为架构更偏向于设计层面，有从设计视图创建解决方案经验的人，一看就知道我在说什么。本文将展示从架构设计视图到.NET多项目解决方案的过程。主要包含以下内容：
（1）演示DDD分层架构到.NET多项目解决方案的映射。
（2）演示DDD分层依赖到.NET项目引用的映射。
（3）演示依赖注入在.NET多项目解决方案中的使用。
1、原始的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）看了架构图谁能跟这代码图对应上？
2、改善的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）再也不用为基础设施层无法引用领域层而在服务层添加不必要的代码了。
3、最新的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）在三种解决方案中，依赖最少，依赖方向一致，最易理解和使用。
