Web applications 体系结构：在何处放置不依赖于任何其他服务或存储库组件的服务类

考虑一个具有存储库层（持久性）、服务层（应用程序）和web（UI）层的web应用程序

考虑一个组件（即ExternalProgramExecutor），它不是UI组件，也不依赖于服务或存储库层中的任何组件

问题是:

• 此组件是否属于服务层
• 该组件是否属于持久层
• 是否应将其与这些层分开处理？如果是，架构的这一部分的名称是什么

---

我希望它是“基础架构层”的一部分。请看一下：

---

谢谢。

问问自己以下问题：

• 它是在坚持什么吗
• 它提供服务吗
• 它所做的这些事情是否与您的应用程序特别相关

第一个问题的答案应该是否定的，因为您已经告诉我们组件没有以任何方式连接到应用程序

第二个问题的答案应该是肯定的，因为所有好的软件组件都提供这样的服务：某种服务

但是，任何值得一试的灵活组件都应该在软件应用程序中的任何地方都能很好地工作，因此真正的问题是：您应该将组件放在哪里，以便最忠实地保存您的web架构

---

毕竟，Web架构只是一种组织机制。如果您试图在一个真正的Web架构参考中找到答案™, 你是。

考虑到你问题的局限性，我想问你独立组件的用途是什么？它主要是围绕某些数据的外观（这将使其成为持久层的一部分），还是应用程序（应用程序层）的域、业务逻辑或工作流的一部分？类似于外部任务执行器，我倾向于认为它是应用程序层的一部分。

从概念上讲，“ExternalProgramExecutor”看起来像一个服务，因此它属于服务层

要了解服务层的详细信息，有两种可能：

服务“ExternalProgramExecutor”与其他服务具有相同的性质，因此它是服务层的另一个“要点”

该服务与其他服务有很大不同，它是服务层的另一个“块”

这种分离保留了一种更务实的观点（实现）：

该服务依赖于相同的功能（相同的UI，相同的持久性访问）：它应该与服务层的其他部分集成，以使用它们的API

该服务本质上是独立的：这是一个机会，不要创建不必要的依赖关系，独立开发它

---

就我个人而言，我会在问题列表中添加另一个问题@Robert asked:

它完全独立于我的应用程序吗

---

对我来说，我通常在我的体系结构中添加一个新的实用程序/框架组件，在这里我放置了完全独立的组件，可以在以后的其他应用程序中重用。

我倾向于将服务视为域模型上的接口，因为这听起来好像不存在这种关系，从这个意义上讲，这听起来不像是一种服务

持久化层负责协调与数据存储的通信，但听起来这个组件在这方面也没有太多工作要做

那么它属于哪一层呢？它真的需要属于一个吗？通过问这些问题，听起来你已经在花时间正确地组织你的对象了。如果您有一个单独的无关组件，您可以：

A） 将其放入使用最多的层中

B） 将它放入自己的程序集中，不要再担心给它贴标签：）

多层（软件）体系结构使用不同的层来分配应用程序的责任，因此我们有：

责任分离

易于查看的工作流

能够以最小的副作用替换层实施。

从第3点开始，如果更改“ExternalProgramExecutor”不需要对其他层进行任何更改。我想这本身就值得一层。 我在一个项目中使用了一个名为“Ext”的层，目的类似

如果更改需要任何更改，请将其添加到需要修改的图层

希望能有所帮助。

根据，这种服务——似乎可以与“Util/Helper”服务相似——应该位于“基础架构层”（src:）

架构

典型的企业应用程序体系结构包括 以下四个概念层：

• 用户界面（表示层）：负责表示 向用户提供信息并解释用户命令
• 应用程序层：该层协调应用程序活动。没有 包含任何业务逻辑。它不保持业务状态 对象，但它可以保存应用程序任务的进度状态
• 域层：此层包含有关业务的信息 域名。业务对象的状态保存在此处。持续性 业务对象及其状态可能被委托给 基础设施层
• 基础结构层：此层用作 支持所有其他层的库。它提供通信 在层之间，实现业务对象的持久性，包含 支持用户界面层的库等

---

嗯，

ExternalProgramExecutor

本身就是一项服务，因为您的应用程序将其用作外部组件

显然