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