我正在使用65个不同的项目重组.NET解决方案，其中包括针对不同产品的多个Web项目。
我正在做这样的事......
Company.Domain
Company.Repository
Company.Services (where services = business logic)
...etc. etc.
我的问题是，您对Company.Services项目有多大嵌套命名空间的想法{i .e。工作流程，SharePoint，临床等。}
为每个服务区域设置不同的程序集会更好吗？
Company.Services.Workflow
Company.Services.SharePoint
Company.Services.Clinical
... etc. etc.
我的想法是将每个服务层分解为自己的程序集会产生过多的项目。但我也担心有一个服务组件会变得非常大。
答案 0 :(得分：1)
首先，将项目拆分为更多程序集会增加编译时间和维护工作量。因此，不要因为你能做到这一点而拆分。拆分你想要隔离概念的地方。
然后，将项目拆分为程序集有助于理解和重新定义依赖项。例如，您不能在项目之间具有循环依赖关系，而没有什么能阻止您在单个项目中具有循环依赖关系。那些循环依赖可能表明你的设计存在缺陷。
另一件事：如果你分裂，试着想一想你如何分裂 - “垂直”或“水平”。考虑一个由多个子域组成的应用程序，如Sales，CRM和ERP。
垂直：将图层隔离到装配体中。将所有存储库放在一个程序集中，另一个程序集中的所有域逻辑和第三个程序集中的所有服务肯定有助于理解依赖关系，如上所述。但这意味着您可以在所有程序集中传播系统中的每个隔离域。 IE浏览器。每个程序集都包含Sales，CRM，ERP所需的逻辑。
水平：将域/域部件隔离到部件中。例如。将与销售相关的所有内容放在一个程序集中，将所有与CRM相关的内容放在另一个程序集中，将所有与ERP相关的内容放在第三个中。所有这些程序集需要或需要在它们之间共享的概念将移动到基础结构项这种方法有助于隔离功能。
您可以将两种策略结合起来，这就是您的建议：
Company.Services.Workflow
Company.Services.SharePoint
Company.Services.Clinical
“Company.Services”是一个垂直分割，而我认为“。Workflow”，“。SharePoint”，“。Clinical”是水平分割。这很容易导致大量项目，基本上是NxM，其中N是层数，M是域数。我会小心的。
我个人喜欢垂直拆分，将（子）域隔离到项目中，并将基础架构/共享概念移动到他们自己的项目中。
此方法支持重用和可配置的产品系列，其中不同的客户端接收项目的不同配置。
基础设施项目可以被其他项目重用，这很好。并且可以根据需要组合子域项目以形成完整的应用程序。例如，如果应用程序需要CRM功能，则仅部署CRM模块。
一个具体的例子，我有一个更大的项目，包括：
基础设施：
域：
注意：域项目之间可能存在依赖关系，例如：销售模块使用来自CRM的东西。
作为最后的注释：再次，不要为了吐痰而分开。如果项目足够大并且您有一定的要求（可重用性，可配置性......），那将是最有意义的。
答案 1 :(得分：0)
不要考虑装配的尺寸。只有在有可能逐个使用它们的情况下，才会将不同项目中的服务分开。如果您的所有产品同时使用所有服务，则将它们分开是没有意义的。
问题中确实没有足够的信息来做出这个决定。这取决于部署方案，团队规模和许多其他因素。如果您只是想让它可以维护，请与您的同事交谈并找出最适合您的人。