我在想我應該如何組織我的項目。構建項目的最佳方式是什麼？
我們有一些項目（重新）在其他項目中使用。
我的意思是，我們的數據項目和模型的項目在一到許多其他項目使用。
我真的知道的是如何構建這種類型的項目，什麼是最好的方式來命名呢？
在一個標準的3層應用程序，是想是這樣的：
任何其他的想法？
在每個公司我的工作，他們得到了不同的方式來組織它，有一個比另一種更好？你使用哪一個，你更喜歡哪一個？爲什麼？
Thx！
對於數據層，我通常使用：
Company.ProjectName.Data（即AdventureWorks.OrderManager.Data）
對於業務層，我更喜歡像 「ObjectModel」（我已經使用「業務」或「業務邏輯」，但這是數據在對象/類中彙集到一起的領域，爲什麼不把它命名呢？）。
Company.ProjectName.ObjectModel（即AdventureWorks.OrderManager.ObjectModel）
對於UI，我想無論是普通的老 「UI」 或 「演示」 ......
Company.ProjectName。演示（即AdventureWorks.OrderManager。演示）
那差不多就是我做的，除了香港專業教育學院有一對夫婦圖書館項目在哪裏我試圖把我所有的可重用代碼。然後我的模型和DAL坐在這些圖書館的頂部，只是增加項目具體情況給他們
軟件架構依賴於軟件來構建的類型。如果你想進行內核編程，與進行應用程序開發相比，其他原則適用。當你要做物理模擬，天氣預報軟件，軟件IDE或編譯器時，還有另一個原則適用。
我假設你想要做應用程序開發。那麼，你很可能會想要圍繞你將要反映的領域設計你的軟件。但即使如此，還是有很多選擇。
欲瞭解更多關於這個主題的更多信息，我強烈建議您從Eric Evans和Applying Domain-Driven Design and Patterns從Jimmmy Nilsson讀取Domain Driven Design。
我目前工作中的前端Web應用程序，有一個3層架構：
它有一個分層架構中，並在應用程序層中的層是：
這只是一個例子項目結構，最終結果將取決於應用程序的類型。您可以在my answer至this question的包裝分部和命名策略中閱讀更多內容。
您可以根據需要添加/交換/刪除圖層。例如，在SOA中，您可以在應用層或服務層之上分層Web服務層，以便ESB（企業服務總線）可以連接到您的應用程序或服務。如果任何這些都不可能或者看起來非常困難，那麼您沒有最佳的架構和設計。
在考慮項目的結構，並允許像上面的場景中，你希望你的模塊和組件的一些重要屬性是：
您可以通過設計低耦合度和高內聚度來實現此目的。通過按功能/抽象級別對模塊進行分組來選擇分層架構是一個好的開始。在每個層次中，進一步按功能進行分組也是有幫助的。讓每個更具體的層只取決於更一般層的接口也會減少耦合。
大多數情況下，我使用微軟模式推薦的分層體系結構&實踐Application Architecture for .NET: Designing Applications and Services。 Document描述了實現它的體系結構和.NET技術。
