This post describes how to spot and improve a Helix module that exhibits Unearned Foundation Status. It's part of a series documenting Helix Smells - some of the common pitfalls of Sitecore development when following the Helix architecture.
When you have a single consumer of a piece of functionality, you usually don't have enough context to understand how it should be generalized. So when a second dependent feature does materialise, its requirements will often be slightly different to what you originally predicted. In that scenario, the Foundation code will likely need to be refactored (see the perils of the Fat Foundation).
This post describes how to spot and improve a Helix module that exhibits Unearned Foundation Status. It's part of a 
Symptoms
A Foundation module has one dependent Feature module, and no dependent modules in the Project or Foundation layers.Why does it occur?
A developer predicted that some functionality might need to be reused in future, and decided to solve the problem in advance.Whats problems does it cause?
When a developer sees a Foundation module in your solution, there is an implicit promise that it has multiple dependencies. If that turns out to be incorrect, it can be confusing and lead to a loss of confidence in the system's design.When you have a single consumer of a piece of functionality, you usually don't have enough context to understand how it should be generalized. So when a second dependent feature does materialise, its requirements will often be slightly different to what you originally predicted. In that scenario, the Foundation code will likely need to be refactored (see the perils of the Fat Foundation).
What's the solution?
A place in the Foundation layer is a privilege that needs to be earned. Don't add anything to a Foundation module unless there is very good reason. There should be at least 2 dependent modules, and you should be confident that you have enough context to adequately understand the generalization.When can I ignore it?
Of course you need to be pragmatic. If you've planned far enough ahead that you're confident that other modules will consume the exact public interface offered by your Foundation code, then go ahead.Related Reading
- The Unearned Foundation Status Helix smell is aligned with the 'Speculative Generality' code smell (aka 'Premature Generalization')
- Unearned Foundation Status could be the cause of a Fat Foundation module,
- See the Principles of Package Coupling for insight in to devising an appropriate abstraction.
This post is part of a series describing Helix Smells. I'm likely to revise it occasionally. If you have any suggestions, contact me on Twitter
Comments
Post a Comment