项目目录(包、模块)结构
在项目的开发阶段,目录结构的划分往往被看做是迈向成功的第一步。这一步的迈出往往伴随着很多方面的权衡(考量),总的来说是两个方面的考量:业务方面和技术方面。
- 业务方面的考量包括:限界上下文、子域、业务模块。
- 技术方面的考量包括:软件架构(分层架构、六边形架构)、构造型分类。
目录结构构成
常见的项目的目录结构基本上由:领域名(domain)、层名(layer)、构造型名(stereotype)、业务模块名(module)这四个部分组成。
领域(业务域、子域)名称
在《领域驱动设计》中的领域通常是指一个业务域,是一个特定的业务范围。同类项目中的业务可能雷同,但对于大多数的项目要解决的业务(问题)来说不会超出所在业务域的范围,因此在项目的目录(包、模块)结构中包含业务域的名称能起到限界作用。比如:产品目录子域(Catalog)、订单子域(Order)、物流子域(Shipping)、发票子域(Invoice)等等。
分层架构中层次名称
在项目的目录结构中显式的引入层名是一种技术考量,更具体一些是编码的考量。分层架构是一种从混乱到有序的解决方案(架构模式)。它的做法是将一个应用程序(流程)划分为多组子任务,其中每组子任务都位于特定抽象层中。例如:分层架构在应用系统的后端开发中,常将一个应用系统划分为三层架构或者四层架构。
三层架构:
- 表现层(Presentation)
- 业务逻辑层(Business)
- 持久层(Persistence)
四层架构:
- 表现层(Presentation)
- 应用(逻辑)层(Application)
- 领域层(Domain)
- 基础设施层(Infrastructure)
在四层架构中的基础设施层要比三层架构中的持久层的功能多一些。
在应用系统开发中的分层架构并不是严格意义上的分层架构。真正的分层表示为上层只能依赖下层,是单向依赖,不能存在双向依赖。具体来说有以下特点:
- J 层依赖 J - 1 层,J + 1 层依赖 J 层。
- J - 1 层不会依赖 J 层,J 层也不会依赖 J + 1 层。
- J + 1 层也不会依赖 J - 1 层。
层与层之间通过数据的封装、转换或者直接使用来做到隔离。
在追求性能和灵活性方面,出现了两种分层变种:宽松的分层系统(Relaxed Layered System)和通过继承进行分层(Layering Through Inheritance)。我们将简要讨论 宽松的分层系统,因为普遍地应用系统采用的就是宽松的分层系统。
宽松的分层系统表示:每层都可以使用它的下层服务,而不仅仅是下一层的服务。每层都可能是半透明的,这意味着有些服务只对上一层可见,而有些服务对上面的所有层都可见。
就算是严格地分层架构或者宽松的分层架构,都表明是上层依赖下层。但在实际地应用系统的架构中并没有完全遵循这种依赖关系,因为架构人员需要在整体架构与分层架构之间进行摇摆球式思考。比如:在领域(Domain)层中的 Repository 接口的实现类往往会放在基础设施(Infrastructure)层中,这显然违反了分层架构中的单向依赖关系。这样的问题有两种解决方案:一是诚然接受。二是将领域层中的 Repository 接口的实现类放置在领域层内。<