似乎使用.NET核心框架有很多好處，我們正在研究這些以查看是否/何時應該遷移我們的應用程序。.NET核心世界中的體系結構
.NET Core中真正吸引人的哲學之一就是僅使用.NET框架所需的部分，通過 Nuget包加載這些。
是我們遷移，那麼我真的很喜歡我們自己的框架，以反映.NET核心方法的瘦肉率。目前，它更接近完整的.NET框架方法，我們加載相當「胖」的DLL。我還沒有看到關於如何最好地構建一個處理.NET Core的應用程序的任何具體建議，所以我在此建議之後。
爲了簡單起見，讓我們想象，我們只有兩個應用：應用-A和App-B。
這兩個應用程序都需要訪問存儲過程訪問的SQL中保存的數據。 App-A與App-B不同，但它們是相關的，所以您可以想象一些存儲過程僅由App-A調用，有些僅由App-B調用，另一些則由兩者調用。
所有調用這些存儲過程的代碼都保存在一個名爲「SQL-DLL」的公共DLL中。是的，DLL公開了特定於App-A和App-B的接口，但該DLL仍包含所有代碼，因此可以被認爲是「胖」而不是「瘦」。
對於剛剛2應用程序，一個可以考慮拆分此爲3個DLL文件：爲App-A只是一個包含電話，一個只是爲App-B和一個用於所有常見的電話呼叫。但是，如果你有（說）10個應用程序呢？排列變得更高，並且很快就不清楚在哪些DLL中存在哪些調用。
更好的辦法是把DLL分成更小的功能DLL--有點像「微服務」？一個用於所有客戶詳細信息的DLL，一個用於所有訂單詳細信息的DLL，一個用於所有...的DLL，但「GetCustomerOrders」屬於客戶或訂單？嗯。
如果任何人有保持代碼的簡潔性爲核心的.NET世界任何好的建議，那麼請不要讓我知道。
另外，每個應用程序有一個Visual Studio解決方案，每個解決方案都有共享的項目。有人建議將共享庫作爲Nuget包而不是項目，但我認爲這會使調試和TDD更難。對此有何想法？
最後，如何最好地在源代碼庫（例如TFS）中進行組織。目前，共享項目導致相對路徑包含很多「../../」，這在Visual Studio中可以正常工作，但當Nuget軟件包不在其預期路徑中時，可能會在構建服務器上導致問題。
我知道我在這裏問了很多，但任何/所有的建議將不勝感激！
基於非常意見的問題，你在這裏......你不應該把它分解成組件。查看DDD中的「有界上下文」，瞭解何時以及何時不將模型分割成不同的有界上下文，例如Martin Fowler關於有界上下文的觀點http://martinfowler.com/bliki/BoundedContext.html – Tseng
嗨，曾經我想我試圖確定.NET CORE應用程序的設計是否應該與完整的.NET應用程序的設計不同。在某些方面，在一個被故意設計爲儘可能「精益」的框架之上，放置一個「胖」的應用程序將是一件恥辱。 – DrGriff
它獨立於所討論的框架。在.NET Core之前編寫精益和模塊應用程序是可能的，未來將如此。現在唯一的區別是，框架默認是模塊化的和獨立的（可以並排運行多個版本）。當您創建應用程序時，沒有其他更改 – Tseng