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