2

我正在重新组织一个包含 65 个不同项目的 .NET 解决方案，其中包括针对不同产品的多个 Web 项目。

我正在考虑做这样的事情......

Company.Domain
Company.Repository
Company.Services (where services = business logic)
...etc. etc.

我的问题是，您对 Company.Services 项目因许多嵌套命名空间而变得太大有什么想法 { 即 工作流、SharePoint、临床等 }

为每个服务区域设置不同的组件会更好吗？

Company.Services.Workflow
Company.Services.SharePoint
Company.Services.Clinical
... etc. etc.

我的想法是，将每个服务层分解成自己的程序集会产生过多的项目。但我也担心拥有一个服务程序集可能会变得非常大。

4

2 回答 2

1

首先，将项目拆分为更多的程序集会增加编译时间和维护工作。所以不要因为你能做到就分裂。在要隔离概念的地方拆分。

再说一次，将项目拆分为程序集有助于理解和具体化依赖关系。例如，您不能在项目之间建立循环依赖关系，而没有什么能阻止您在单个项目中建立循环依赖关系。这些循环依赖可能表明您的设计存在缺陷。

另一件事：如果你分裂，试着想想你是如何分裂的——“垂直”或“水平”。考虑一个由多个子域（如销售、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 模块。

一个具体的例子，我有一个更大的项目，包括：

基础设施：

  • Company.Commons
  • 公司.域名
  • 公司.消息
  • 公司.坚持
  • 公司.Web.Mvc
  • 等等

域：

  • 公司.销售
  • 公司CRM
  • 公司.ERP
  • 公司.POS
  • 等等

注意：域项目之间可能存在依赖关系，例如销售模块使用来自 CRM 的东西。

最后一点：再一次，不要为了吐口水而分裂。如果项目足够大并且您有某些要求（可重用性，可配置性......），这是最有意义的。

于 2013-02-14T13:00:58.667 回答
0

不要考虑组件的大小。只有在有机会可以一一使用的情况下，我才会将不同项目中的服务分开。如果您的所有产品同时使用所有服务，那么将它们分开是没有意义的。

问题中确实没有足够的信息来做出这个决定。这取决于部署方案、团队规模和许多其他因素。如果您只是想让它可维护，请与您的同事交谈并找出最适合你们所有人的方法。

于 2013-02-14T12:38:48.407 回答