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.

私の考えでは、各サービス レイヤーを独自のアセンブリに分割すると、過剰な量のプロジェクトが作成されます。しかし、1 つのサービス アセンブリが非常に大きくなる可能性があるという懸念もあります。

4

2 に答える 2

1

まず第一に、プロジェクトをより多くのアセンブリに分割すると、コンパイル時間とメンテナンスの労力が増加します。できるからといって、ただ分割しないでください。概念を分離したい場所で分割します。

繰り返しますが、プロジェクトをアセンブリに分割すると、依存関係を理解し​​、具体化するのに役立ちます。たとえば、プロジェクト間で循環依存関係を持つことはできませんが、単一のプロジェクト内で循環依存関係を持つことを止めるものは何もありません。これらの循環依存は、設計の欠陥を示している可能性があります。

別のこと：分割する場合は、「垂直」または「水平」に分割する方法を考えてみてください。Sales、CRM、ERP などの複数のサブドメインで構成されるアプリケーションを考えてみましょう。

垂直方向: レイヤーをアセンブリに分離します。前述のように、すべてのリポジトリを 1 つのアセンブリに、すべてのドメイン ロジックを別のアセンブリに、すべてのサービスを 3 番目のアセンブリに配置すると、依存関係を理解するのに役立ちます。ただし、これは、システム内のすべての分離されたドメインをすべてのアセンブリに分散させることを意味します。すなわち。すべてのアセンブリには、Sales、CRM、ERP に必要なロジックが含まれています。

水平方向: ドメイン/ドメイン パーツをアセンブリに分離します。たとえば、販売に関連するすべてのものを 1 つのアセンブリに、CRM に関連するすべてのものを別のアセンブリに、ERP に関連するすべてのものを 3 つ目のアセンブリに配置します。これらすべてのアセンブリが必要とする、またはアセンブリ間で共有する必要がある概念は、インフラストラクチャ プロジェクトに移動されます。このアプローチは、機能を分離するのに役立ちます。

両方の戦略を組み合わせることができ、それがあなたが提案していることです:

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

「Company.Services」は縦割りですが、 「.Workflow」「.SharePoint」「.Clinical」は横割りだと思います。これは、基本的に NxM (N はレイヤーの数、M はドメインの数) の大量のプロジェクトに簡単につながる可能性があります。私はそれに気をつけます。

個人的には、垂直に分割して (サブ) ドメインをプロジェクトに分離し、インフラストラクチャ/共有概念を独自のプロジェクトに移動するのが好きです。

このアプローチは、さまざまなクライアントがプロジェクトのさまざまな構成を受け取る再利用および構成可能な製品ラインをサポートします。

インフラストラクチャ プロジェクトは他のプロジェクトで再利用できます。これはすばらしいことです。また、必要に応じてサブドメイン プロジェクトを組み合わせて、完全なアプリケーションを形成することもできます。たとえば、アプリケーションに CRM 機能が必要な場合にのみ、CRM モジュールを展開します。

具体的な例として、次のもので構成されるより大きなプロジェクトがあります。

インフラストラクチャー：

  • Company.コモンズ
  • Company.ドメイン
  • Company.Messaging
  • Company.Persistence
  • 会社.Web.Mvc
  • 等々

ドメイン:

  • Company.売上
  • 会社.CRM
  • 会社.ERP
  • 会社.POS
  • 等

注: ドメイン プロジェクト間に依存関係がある場合があります。たとえば、販売モジュールは CRM のものを使用します。

最後の注意として、繰り返しますが、唾を吐くために分割しないでください。プロジェクトが十分に大きく、特定の要件 (再利用性、構成可能性など) がある場合は、最も理にかなっています。

于 2013-02-14T13:00:58.667 に答える
0

アセンブリのサイズについて考えないでください。サービスを個別に使用できる可能性がある場合にのみ、サービスを異なるプロジェクトに分けます。すべての製品がすべてのサービスを一度に使用する場合、それらを分離しても意味がありません。

この決定を下すには、質問には十分な情報がありません。これは、展開シナリオ、チームの規模、およびその他の多くの要因によって異なります。メンテナンスしやすいものにしたいだけなら、同僚と話し合って、全員にとって何が最善かを考えてください。

于 2013-02-14T12:38:48.407 に答える