Kent Beck introduces his wonderful 2008 book on Implementation Patterns by asserting that:
“Design Patterns talk about decisions you might make a few times a day while developing, typically decisions that regulate the interaction between objects. [Whereas] you apply Implementation Patterns every few seconds while programming.”
Missing from this quote is the frequency of defining Application Architecture concerns. This model clarifies three partitions as business-domain agnostic or business-domain specific:
- Specific: Application Implementation can be considered the unit tests and functional source offering ‘just enough’ capability.
- Specific: Application Design can be considered the interaction (contract) between objects to minimize duplicate code.
- Agnostic: Application Architecture can be considered the structure that formulates dependency groupings of objects for future flexibility.
This post asserts the criticality of Application Architecture maintaining independence from a business domain, and that a domain dependency is actually a 'structure smell'.
The term ‘code smell’ is attributed to Kent although first published by Martin Fowler in 1999. According to a current post on Wikipedia a “code smell is any symptom in the source code… that possibly indicates a deeper problem”.
Extending ’code smell’ to ‘structure smell‘ provides a way to talk about symptoms in the Application Architecture that possibly indicate a deeper problem. So, why should we care?
If we return to Kent’s pattern assertions we can deduce that the cost of refactoring a single instance of an Implementation is trivial. The cost of refactoring a single instance of a Design more costly.
However, the cost of refactoring a brittle business-function dependent Application Architecture might be considerable! Therefore, those concerned with application maintainability, as businesses evolve, vigilantly look for ’structure smells’ indicating the possibility Application Architecture is ’hard-wired’ to optimize a particular business-domain.
- The terms “business-domain agnostic” and “business-domain specific” convey scope. For example, a static utility method manipulating a String may be utilized for a Payroll or an Invoicing application – it makes no difference. However, a calculation for determining the current market value of a kilowatt of generated electricity may be optimized for a unique Financial application. The intent is to help express the notion that some forward-thinking Application Architectures are established to serve multiple (if not unlimited) business domains.
- Alexander von Zitzewitz stipulates that you should “compare your [application] architecture with the dependency structure of your code and list all places where the code does not conform to your [application] architecture”.