洋葱建筑 - 选择正确的"模块"途径

时间:2018-03-15 13:09:53

标签: design-patterns domain-driven-design onion-architecture

我已经研究了洋葱建筑几周了,我偶然发现了一个技术难题。

当我说" module"请注意,我指的是项目的概念。为了更清楚它与以下内容兼容: module = .NET Assembly / Java gradle模块

到目前为止,我在大多数洋葱建筑项目中看到过两种模块模式:

1 - 每个图层都拥有自己的模块,因此它具有:

  • 域的实体
  • 域的接口
  • 服务接口
  • 服务
  • 基础设施数据
  • 基础设施登录
  • UI

2 - 所有相关模块都封装在一个模块中:

  • 核心(域实体,域接口,服务接口,服务)
  • 基础设施(基础设施数据,基础设施日志记录)
  • UI

第二种方法对我来说更简单,但我不确定它是否会在将来导致依赖性问题。有什么建议吗?

1 个答案:

答案 0 :(得分:0)

您拥有的模块越多,对象之间的依赖关系就越不灵活,因为您受到洋葱架构严格依赖方向的限制。

设计#1对我来说似乎过于细化。特别是,将接口与实现分离可防止您从实现模块引用接口模块,这可能是限制性的。有时,A中的对象需要松散地耦合到B中的对象,该对象的接口在A中声明(DDD存储库会浮现在脑海中)。