在基于组件的架构中，大量分离的组件通过一组标准化接口进行通信 - 是否有任何关于在哪里存储/如何对接口进行分组的指南？
极端的解决方案是：
这两个选项对我来说似乎都是错误的 - 第一个不够灵活（例如，如果您只想更改一个界面），第二个是另一个极端，它可能很快升级为维护噩梦。
特别是，我正在寻找不采用上述两个极端的 KILLER 论点以及明显的替代方法。
任何意见表示赞赏。
【问题讨论】：
标签： .net architecture interface components
您通常会创建某种形式的“通用”库，架构中的所有组件都必须引用该库。这是定义和分组所有共享接口、枚举等的地方。
因此，创建扩展或适合框架的库的第一步是引用 Common.DLL。然后，您可以在该特定模块中实现所需的任何一组接口。
您描述的极端解决方案确实非常极端。第一个将非常不灵活，并且基本上会阻碍扩展框架的能力。第二种会非常灵活，但会使您的项目淹没在令人讨厌的单接口 DLL 汤中。
【讨论】：
我使用尽可能少的程序集，目标是单个程序集，同时隔离域的易变区域。当多个程序集明显合适或需要时，我会尽力将同时更改的接口分组到相同的程序集中。
最近关于维护多个程序集的成本进行了一些很好的讨论。 This article 特别擅长描述多个程序集的缺点，观察它们如何在开发时、编译时、部署时和运行时增加成本。
【讨论】：
您不能将接口分组到功能/域区域吗？这样你就可以在中间的某个地方得到一个解决方案。如果没有，我会将所有常用接口放入一个程序集中。
【讨论】：
IMO 组件的接口应该与组件一起存在 - 可能在组件特定的接口程序集中。
任何“通用”数据类型都应与组件分开存在（可能在“通用”或“共享”组件中）。
【讨论】：
所有的反应都很好。我想提倡“适度”的普遍共识。
然而，一个简短的轶事，
我亲眼目睹了整个解决方案随着特定功能程序集的激增而爆炸式增长。我也见过单体方法。重申：你想要介于两者之间的东西。
在我的个人项目中，我使用了很多依赖注入 [DI] 和控制反转 [IoC]，并利用 Castle Windsor Container 来完成很多繁重的工作。我还尽早确定哪些组件需要“广泛”范围，哪些不需要曝光。例如，一个服务（比如容器本身，或者一个事件代理）将被认为是“广泛的”，因为在整个应用程序中可能有很多这个服务的消费者。一个孤立的组件[比如一个特定于业务的日期格式化程序]不会很宽泛，因为除了它特定的业务之外，没有人有兴趣直接使用它。
广泛的接口，我将放置在单独的SomeProductName.Interfaces 程序集中。
业务特定的接口可以放置在它们自己的面向函数的程序集中SomeProductName.SomeStuffForAlice 和SomeProductName.SomeStuffForBob，通常与其实现相同的库。
程序集只是源组织的物理表示——它们本身并不意味着任何东西[即，一个整体的混搭，虽然令人厌恶，但在功能上等同于组织良好的解决方案和每个界面噩梦的令人不安的项目]。
组织约定只有在服务于消费者 [你！开发商！]
【讨论】：
简而言之 如果接口是共享的，那么它们必须被分组到一个公共程序集中，否则它们必须在组件接口程序集中。
更详细一点 如果标准化（即共享）接口之一发生更改，无论您将它放在哪里，您都必须更改实现它的所有组件，无论该接口是在公共组件中还是在组件中。 因此，选项 1 没有特定的缺点，即使如您所说，您可能只需要更改一个界面。 另一方面，在每个组件中复制通用接口也会有一个缺点，请参阅标准冗余问题。
这不是一个特殊的建议，而是从您（明智地）选择具有标准化接口的那一刻起的自然选择。您努力识别它们，发现它们是标准的，现在您将它们分组。
如果实现这些通用接口的组件还具有其他一些特殊接口，则这些接口必须在组件程序集中，因为它们不应暴露给有权访问该通用程序集的其他组件。
【讨论】：
这取决于每个接口的用途：
如果接口的目的是在一组替代供应商和单个消费者之间定义标准协议，则该接口归消费者所有。
如果接口的目的是在单个供应商和一组替代消费者之间定义标准协议，则该接口归供应商所有。
如果接口的目的是在一组替代供应商和一组替代消费者之间定义标准协议，则接口独立。
最后，如果接口被用作降低复杂性的通用方法，它们通常由消费者拥有，并且应该尽可能地定义窄，以便每个接口都支持消费者在特定需求上下文中的需求。
【讨论】：