Thoughts on implementing the *.Abstractions libraries pattern used in dotnet core? #4884
Unanswered
mchandschuh
asked this question in
Ideas
Replies: 2 comments 1 reply
-
+1 It would already be very greate to extract |
Beta Was this translation helpful? Give feedback.
1 reply
-
I'm not really convinced the juice is worth the squeeze here - it's hard to decouple the base abstractions, like |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In general its preferable to only take dependencies that you actually depend on. The dotnet core team took this to heart and broke out several
*.Abstractions
libraries so you could reference all of the concepts pertaining to a particular feature set without having to take on any of the dependencies required by the implementation.If you're not familiar with this pattern, I recommend you take a look at the
Microsoft.Extensions.*
nuget packages.My primary motivation is due to my solution structure. Each service defines a
*.protocols
library. I've grown to accept that these protocol libraries need to take a hard dependency on akka core. Just moments ago I went to add a stream ref to a message and was reminded that my*.protocols
library that would ideally have zero dependencies (except maybe other projects w/out dependencies, domain types, DTOs, common abstractions, etc) is now cluttered w/ akka core and akka streams. I'm starting to get nervous for when we start clustering our services and one unlucky protocol will more than likely need a reference toAkka.Cluster
.Is there an appetite for making this change? It would absolutely be a breaking change, although there are ways to have both co-exist. Both here meaning the
*.Abstractions
libraries as well as the current set of libraries.EDIT: I did some playing around w/ msbuild and it looks like it shouldn't be too hard to automate the creation of
*.Abstractions
libraries as part of ci/cd. I wouldn't recommend this as it would require some heuristic for deciding which files (or portions thereof) to include. Abstractions libraries should contain the abstractions and data types (sans behavior) for the most fundamental concepts contained within the actual implementation library. It does require more maintenance and time to sift through everything, but at the end of the day we'll end up with much cleaner dependency diagrams.Beta Was this translation helpful? Give feedback.
All reactions