refactor(sln): functional grouping of projects #863
Conversation
✅ Deploy Preview for testcontainers-dotnet ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
riezebosch
force-pushed
the
refactor/project-grouping
branch
from
f243e28 to
4f0d4fb
Compare
There was a problem hiding this comment.
Thank you for your pull request. I have been using the updated structure since yesterday. I frequently jump around various modules and must admit that it doesn't appeal to me just yet (I do not like the nesting). Personally, I preferred the previous configuration more, but I will give it a try. Perhaps it will just take some time until I get used to it.
|
The idea for this PR stems from the cohesion theory that functional cohesion is much better than logical cohesion. This is what I nowadays do in projects where I do hexagonal architecture/ports & adapters. I then put the adapters in separate projects and group them into solution folders with the test and integration test projects. It is my experience that there's less jumping around in the solution tree that way since when working on an adapter it makes sense that the tests covering that adapter are nearby. This same theory also applies to some extend to your project, but I can imagine it for you being less ideal. Like you said, when changing something in the "core" you need to update all "adapters" as well. So no hard feelings when it doesn't work out for you. More then happy that you showed the willingness to give it a shot 🤟🏻 |
|
With more modules, this structure may make even more sense. I am currently thinking about minor adjustments. I will prepare a proposal. |
|
You don't need a proposal, you're the maintainer 😎 It would be great if you could cherry-pick my commit and amend it to properly attribute it to me ❤️ |
functional cohesion to ease navigation
riezebosch
force-pushed
the
refactor/project-grouping
branch
from
4f0d4fb to
7f7ccf0
Compare
|
Right now, I am playing around with different configurations, considering generating Visual Studio Solution files for each module automatically. This has the advantage that we do not need to load and compile all projects. However, we need to keep in mind that refactoring may require loading all projects anyway. |
Instead of creating solution files per module, you can also create solution filter files. With that you have still a fully maintained solution with all modules in place, and you can load a specific module also... |
Good idea. Maybe we can put them in the module directory? Then devs can open only the module they are interested in. |
It may be a good idea to collect the set of |
functional cohesion to ease navigation.
It prevents you from jumping up and down in the solution explorer by placing the tests and the sut more close together. Give it a shot and see if you like it.