在分层架构中应用依赖倒置原则
有一种方法可以改进分层架构——依赖倒置原则,它通过改变不同层之间的依赖关系达到改进目的。依赖倒置原则由Robert C.Martin提出,正式的定义为:
高层模块不应该依赖于低层模块,两者都应该依赖于抽象。
抽象不应该依赖于细节,细节应该依赖于抽象。
根据该定义,低层服务(比如基础设施层)应该依赖于高层组件(比如用户界面层、应用层和领域层)所提供的接口(即抽象)。在架构中采用依赖倒置原则有很多种表达方式,这里我们将采用下图中的方式。
依赖倒置原则真的可以支持所有的层吗?
有人认为,在依赖倒置原则中只存在两层、一层位于最上方,一层位于最下方。上方层将实现由下方层定义的抽象接口。按此对上图进行调整,基础设施层将位于最上方、用户界面层、应用层和领域层将作为相同的一层,并且位于下方。对此,你可以保留自己的意见。不要担心,我们将在六边形或端口和适配器架构中对此做详细讲解。
对于上图中的架构,我们可以在领域层中定义资源库的接口,然后在基础设施层中实现该接口:
using Com.Saasovation.Agilepm.Domain.Model.Product;
namespace Com.Saasovation.Agilepm.Infrastructure.Persistence
{
public class EntityFrameworkBacklogItemRepository:BacklogItemRepository
{
public override ICollection<BacklogItem> BacklogItemsCommitedTo(Tenant tenant, SprintId sprintId)
{
//注意了,此处是伪代码
return (ICollection<BacklogItem>)DbContext.BacklogItems.Where(item => item.tenant == tenant && item.sprintId == sprintId);
}
}
...
}
我们应该将关注点放在领域层上,采用依赖倒置原则,使领域层和基础设施层都只依赖于领域模型所定义的抽象接口。由于应用层是领域层的直接客户,它将依赖于领域层接口,并且间接地访问资源库和由基础设施层提供的实现类。应用层可以采用不同的方式来获取这些实现,包括依赖注入、服务工厂和插件。
有趣的是,当我们在分层架构中采用依赖倒置原则时,我们可能会发现,事实上已经不存在分层的概念了。无论是高层和低层,它们都只依赖于抽象,好像把整个分层架构给推平了一样。如果我们将分层架构推平,再向其中加入一些对称性会变得如何?请看六边形架构!
作者:菜鸟吊思
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利.
施主您好,贫僧接受供养,施主一粒米,大如须弥山!南无阿弥陀佛!
您学习别人出学费,只需先扫红包码,后扫支付码!
![](https://files.cnblogs.com/files/sad-bird/红包码.bmp)