我正致力於用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