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[1]:

• 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”[2].

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.

_Marvin

References

1. 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.
2. 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”.