A colleague sent me a link to your article, which I read with interest.
I wasn't - until now - aware of the term 'feature slice'.
From my Java background I'm used to the term 'package by feature' which describes the same concept.
(see e.g. dev.to/rcosteira79/package-by-feat...).
And while I'm mostly in agreement with your article, I was kinda expecting something else.
Just in case you're not aware of it - there is a 'Vertical slice architecture' which embraces slices with low coupling and locality on an - maybe radical - architectural level.
See for example here: jimmybogard.com/vertical-slice-arc... (from the guy who wrote AutoMapper, none the less).
Giving every 'slice' maximum independence.
But this also complies with one of the more practical 'principles' of software development I came across:
Write code that is easy to delete, not easy to extend.
However, such 'sliced' approaches of course bring their own problems (e.g. enforce some invariant across the system or changing some truth in all relevant slices to keep consistent).
That is, how much 'common code' to put into such an setup.
Take care,
utg
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Dear Mr. Christochowitz
A colleague sent me a link to your article, which I read with interest.
I wasn't - until now - aware of the term 'feature slice'.
From my Java background I'm used to the term 'package by feature' which describes the same concept.
(see e.g. dev.to/rcosteira79/package-by-feat...).
And while I'm mostly in agreement with your article, I was kinda expecting something else.
Just in case you're not aware of it - there is a 'Vertical slice architecture' which embraces slices with low coupling and locality on an - maybe radical - architectural level.
See for example here: jimmybogard.com/vertical-slice-arc... (from the guy who wrote AutoMapper, none the less).
Giving every 'slice' maximum independence.
But this also complies with one of the more practical 'principles' of software development I came across:
Write code that is easy to delete, not easy to extend.
However, such 'sliced' approaches of course bring their own problems (e.g. enforce some invariant across the system or changing some truth in all relevant slices to keep consistent).
That is, how much 'common code' to put into such an setup.
Take care,
utg