注：此⽂转载⾃领域驱动设计（DDD）：项⽬⽬录（包、模块）结构
DDD项⽬⽬录（包、模块）结构
在项⽬的开发阶段，⽬录结构的划分往往被看做是迈向成功的第⼀步。这⼀步的迈出往往伴随着很多⽅⾯的权衡（考量），总的来说是两个⽅⾯的考量：业务⽅⾯和技术⽅⾯。 业务⽅⾯的考量包括：限界上下⽂、⼦域、业务模块。
技术⽅⾯的考量包括：软件架构（分层架构、六边形架构）、构造型分类。 ⽬录结构的分层
常见的项⽬的⽬录结构基本上由：领域名（domain）、层名（layer）、构造型名（stereotype）、业务模块名（module）这四个部分组成。 1. 领域（业务域、⼦域）名称
在《领域驱动设计》中的领域通常是指⼀个业务域，是⼀个特定的业务范围。对于⼤多数的业务（问题）
来说不会超出所在业务域的范围，因此业务域的名称在项⽬的⽬录（包、模块）结构中能起到限界作⽤。⽐如：产品⽬录⼦域（Catalog）、订单⼦域（Order）、物流⼦域（Shipping）、发票⼦域（Invoice）等等。
2. 层名称
防水之乡在项⽬的⽬录结构中显式的引⼊层名是⼀种技术考量，更具体⼀些是编码的考量。分层架构是⼀种从混乱到有序的解决⽅案（架构模式）。它的做法是将⼀个应⽤程序（流程）划分为多组⼦任务，其中每组⼦任务都位于特定抽象层中。例如：分层架构在应⽤系统的后端开发中，常将⼀个应⽤系统划分为三层架构或者四层架构。
三层架构：
表现层（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 接⼝的实现类放置在领域层内。
3. 构造型名称（stereotype）
假如古代也有手机构造型使⽤书名号（《》）来表⽰，⽤于区分不同地建模元素。
如：实体（entity）、枚举（enumeration）、异常（exception）、查询（query）、事件（event）、
资源库（repository）、服务（service）、控制器（controller）等等都是常见的构造型。
有些项⽬在划分⽬录结构时，会将构造型显式的引⼊到⽬录结构中，这是⼀种归类的组织⽅式。
如entity包，service包等。
点火头
4. 业务模块（module）
在分析⼀个业务（问题）域时，会将⼀个业务域划分为多个业务模块。⽐如在商店（Store）⼦域中会被划分为：商店员⼯（Staff）、商店会员（Member）、商店⾓⾊（Role）等等。
看到这⾥，如果你还迷茫，那我再来举个例⼦：
商品领域 划分成 商品品牌模块、商品类⽬模块、商品模块等
所以，领域是业务界限，业务模块是按抽象出的概念。
常见的⽬录结构
马力宏
在分别对⽬录（包）结构的构成元素做了简单介绍后，下⾯要开始具体探讨由这些元素组合⽽成的⽬录结构了。
业务域名.层名.*
业务域名.层名.业务模块名.*
业务域名.构造型名.*
业务域名.构造型名.业务模块名.*
业务域名.（层名 & 构造型名）.*
业务域名.（层名 & 构造型名）.业务模块名.*
业务域名.业务模块名.*
业务域名.业务模块名.层名.*
业务域名.业务模块名.构造型名.*
业务域名.业务模块名.（层名 & 构造型名）.*
业务域名.（业务模块名 & 层名 & 构造型名）.*
（构造型名 || 层名）.业务域名.业务模块名.*
补充说明：
省略包（package）的反向域名（org.mallfoundry.*）前缀的部分。
领域看作是业务域，其中业务域名是业务域 名，⽽不是业务 域名。
（层名 & 构造型名）是⼀种混合，表⽰在同⼀级别的⽬录（包）结构上同时存在按层和按构造型划分的两种⽅式。
我的理解
我的理解是：
领域名⼀般在最上
剩余三个，综合考量，谁最重要谁在前，不重要的也可以省略。
层名中的应⽤层（Application）是很重要的⼀个考量点，如果应⽤层编排时会⽤到多个模块，则应⽤层不能低于模块名。本⼈做的项⽬⼤多是
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议