Architecture in the .NET Core world : <p>There appear to be many benefits of using the .NET Core framework and we are investigating these to see if/when we should migrate our applications.</p>

<p>One of the really appealing philosophies in .NET Core is that of only utilizing the parts of the .NET framework that are required, loading these <em>via</em> Nuget packages.</p>

<p>Were we to migrate, then I'd really like our own framework to mirror the leanness of the .NET Core approach.  Currently, it's more allied to the full .NET framework approach where we load fairly "fat" DLLs.  I've not seen any specific advice on how best to architect an application addressing .NET Core, so am after advice here.</p>

<p>For simplicity's sake, let's imagine that we have just two applications: App-A and App-B.</p>

<p>Both applications need to access data held in SQL which is accessed by stored procedures.  App-A is different to App-B, but they are related, so you can imagine that some stored-procedures are called only by App-A, some only by App-B and some are called by both.  </p>

<p>All the code that calls these stored procedures is held in a common DLL called "SQL-DLL".  Yes, the DLL exposes interfaces that are specific to App-A and App-B, but the DLL still contain ALL the code and so can be considered "fat" rather than "lean".</p>

<p>For just 2 applications, one could consider splitting this into 3 DLLs: one just containing calls for App-A, one just for calls for App-B and one for all common calls.  But, what if you have (say) 10 applications?  The permutations become much higher and it soon becomes unclear which calls exist in which DLLs.</p>

<p>Better maybe to split the DLL into smaller functional DLLs - a bit like "micro-services"?  One DLL for all the Customer details, one DLL for all the Order details, one DLL for all the....but there again, does "GetCustomerOrders" belong in Customer or Orders? Hmmm.</p>

<p>If anyone has any good advice on keeping code lean for the .NET Core world, then please do let me know.</p>

<p>In addition, we have one Visual Studio solution per application, and each solution has the shared Projects.  Some people recommend having the shared libraries as Nuget packages rather than projects, but I think this would make it overall harder to debug and to TDD.  Thoughts on this?</p>

<p>And finally, how best to organize this in the the source repository (e.g. TFS).  Currently, the shared projects result in relative paths that contain lots of "../../" which works fine in Visual Studio, but can cause problems on the build server when Nuget packages aren't in their expected paths.</p>

<p>I know I've asked a lot here, but any/all recommendations would be most appreciated!</p>
