- 架构是高层的设计，若设计有误和理解有误，必将在实现时带来问题。
- 结构是最稳定的，不存在具体技术的依赖。
三层模型与DDD对比
设计方案1
image.png
搭建解决方案
-
DDD.UI用户接口层 ASP.NET MVC空项目 -
DDD.Application应用层类库项目 -
DDD.Domain领域层类库项目 -
DDD.Infrastructure基础设施层类库项目 -
DDD.Repository仓储类库项目
DDD分层架构
项目间引用
-
DDD.UI添加DDD.Application、DDD.Domain、DDD.Infrastructure、DDD.Repository的引用 -
DDD.Application添加DDD.Domain、DDD.Infrastructure的引用 -
DDD.Domain添加DDD.Infrastructure的引用 -
DDD.Repository添加DDD.Domain、DDD.Infrastructure引用
项目间引用
依赖注入
- 为更彻底的解耦，对依赖注入的实现应用依赖倒置原则。
- 不依赖任何具体的IoC框架及其类和版本
- 在基础设施层中实现2中不同IoC框架
- 在使用时展示通过直接注入和通过反射两种方式
- 通过反射可将IoC的实现依赖通过配置文件管理
依赖注入
using System;
namespace DDD.Infrastructure.IoC
{
/// <summary>
/// IoC抽象接口
/// </summary>
interface IIoCContainer
{
object GetInstance(Type type);
T GetInstance<T>();
T[] GetInstances<T>();
void Init();
void Add();
}
}
namespace DDD.Infrastructure.IoC
{
/// <summary>
/// IoC管理类
/// </summary>
class IoCEngine
{
private static IIoCContainer _container;
public static IIoCContainer Container
{
get
{
return _container;
}
}
public static void Init(IIoCContainer container)
{
container.Init();
_container = container;
}
}
}
image.png
问题：
- 更像是以基础设施层为核心
- 仓储无法置于基础设施层
- 领域层对外有依赖
- 代码和架构无法对应
设计方案2
DDD
项目间引用
-
DDD.UI展现层添加DDD.Application、DDD.Domain、DDD.Infrastructure的引用 -
DDD.Application添加DDD.Domain、DDD.Infrastructure的引用 -
DDD.Infrastructure添加DDD.Domain的引用
改善
- 领域层不再依赖基础设施层
- IEntity和IRepository接口定义在领域层
- Repository仓储真正在基础设施层实现
优势
- 代码图和架构图完美对应
- 领域层为中心
- 不用为基础设施层无法引用领域层，而在领域层添加不必要的代码。
设计方案3
image.png
项目间引用关系
-
DDD.UI添加DDD.Application、DDD.Domain、DDD.Infrastrcutre的引用 -
DDD.Application添加DDD.Domain的引用 -
DDD.Infrastrcutre添加DDD.Application、DDD.Domain引用
优势
- 将IService接口定义在应用层
- 进一步将所有哦依赖的接口定义在领域层和应用层，包括 依赖注入管理。
