考虑一个具有存储库层(持久性)、服务层(应用程序)和 Web (UI) 层的 Web 应用程序。
考虑一个组件(即 ExternalProgramExecutor),它不是 UI 组件并且不依赖于服务或存储库层的任何组件。
问题是:
- 这个组件是否属于服务层?
- 这个组件是否属于持久层?
- 是否应该与这些层分开处理?如果是这样,这部分架构的名称是什么?
考虑一个具有存储库层(持久性)、服务层(应用程序)和 Web (UI) 层的 Web 应用程序。
考虑一个组件(即 ExternalProgramExecutor),它不是 UI 组件并且不依赖于服务或存储库层的任何组件。
问题是:
问自己以下问题:
第一个问题的答案应该是否定的,因为您已经告诉我们该组件没有以任何方式与应用程序挂钩。
第二个问题的答案应该是肯定的,因为这是所有好的软件组件都提供的:某种服务。
但是任何称职的灵活组件都应该在软件应用程序中的任何地方都能很好地工作,所以真正的问题是:你应该把组件放在哪里,以便最忠实地保留你的 Web 架构?
毕竟,Web 架构只是一种组织机制。如果您试图在 The One True Web Architecture Reference™ 中找到答案,那么您做错 了。
就个人而言,我会在@Robert 提出的问题列表中添加另一个问题:
对我来说,我通常会在我的架构中添加一个新的 Utility/Framework 组件,这是我放置完全独立的组件的地方,这些组件可以稍后在其他应用程序中重用。
根据DDD的说法,这种服务——似乎可以与“Util/Helper”服务同化——应该在“基础设施层”中(来源:InfoQ)
建筑学
典型的企业应用架构由以下四个概念层组成:
- 用户界面(表示层):负责向用户呈现信息并解释用户命令。
- 应用层:该层协调应用活动。它不包含任何业务逻辑。它不保存业务对象的状态,但可以保存应用程序任务的进度状态。
- 领域层:该层包含有关业务领域的信息。业务对象的状态保存在这里。业务对象的持久性及其状态可能被委托给基础设施层。
- 基础设施层:该层充当所有其他层的支持库。它提供层之间的通信,实现业务对象的持久化,包含用户界面层的支持库等。
从概念上讲,“ExternalProgramExecutor”看起来像一个服务,所以它属于服务层。
进入服务层的细节,有两种可能:
这种析取保留了更实用的观点(实现):
好吧,ExternalProgramExecutor
它本身就是一项服务,因为您的应用程序将其用作外部组件。
显然,如果您不打算将该组件作为应用程序项目的一部分,则不能将该服务放入您的应用程序中。source code
因此,您实际上将Gateway
在您的项目中拥有该服务/组件。为了做到这一点SOLID
,您的网关将是抽象的,您的问题是您应该从哪里引用该抽象网关。
答案完全取决于 ExternalProgramExecutor(以及网关)提供什么样的功能,以及您的项目如何使用该功能。从应用程序的顶层到底层(DAL -> ... -> UI),而抽象功能不是该层的一部分。找到正确的层后,使用该层中的网关,底层不应该在运行时知道具体网关的存在。
我倾向于将服务视为您的域模型上的接口,并且由于听起来这种关系不存在,因此从这个意义上说,它听起来不像是服务。
您的持久层调解与您的数据存储的通信,但听起来这个组件在那里也没有太多工作要做。
那么它属于哪一层呢?它真的需要属于一个吗?通过提出这些问题,听起来您已经在花时间正确地组织您的对象。如果您有一个无关组件,您可以:
A) 放到最常用的层
B)将其放入自己的组件中,不再担心标记它:)
多层(软件)架构使用不同的层来分配应用程序的职责,因此我们有:
从第 3 点开始,如果更改“ExternalProgramExecutor”不需要对其他层进行任何更改。我想这本身就值得一层。我在一个具有类似目的的项目中使用了一个名为“Ext”的层。
如果更改需要任何更改,请将其添加到需要修改的层。
希望能帮助到你。
我希望它将成为“基础设施层”的一部分。请看一下:
http://en.wikipedia.org/wiki/Common_layers_in_an_information_system_logical_architecture
谢谢。
鉴于您的问题的限制,我会问您独立组件的目的是什么?它主要是围绕某些数据的外观(这将使其成为您的持久层的一部分),还是它是应用程序(您的应用程序层)的域或业务逻辑或工作流的一部分?像外部任务执行器之类的东西,我倾向于认为它会成为您的应用程序层的一部分。