在分层架构中应用依赖倒置原则

      有一种方法可以改进分层架构——依赖倒置原则，它通过改变不同层之间的依赖关系达到改进目的。依赖倒置原则由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);

             }

      }

      ...

}

      我们应该将关注点放在领域层上，采用依赖倒置原则，使领域层和基础设施层都只依赖于领域模型所定义的抽象接口。由于应用层是领域层的直接客户，它将依赖于领域层接口，并且间接地访问资源库和由基础设施层提供的实现类。应用层可以采用不同的方式来获取这些实现，包括依赖注入、服务工厂和插件。

      有趣的是，当我们在分层架构中采用依赖倒置原则时，我们可能会发现，事实上已经不存在分层的概念了。无论是高层和低层，它们都只依赖于抽象，好像把整个分层架构给推平了一样。如果我们将分层架构推平，再向其中加入一些对称性会变得如何？请看六边形架构！