There is a thought that has been floating in my mind like an infectious song over the last few weeks and it is Niclas Nilsson’s fault! He posed the question “AOP- Why don’t people get it?” The essence of AOP is the application of old fashioned patterns, mixins and interceptors, using, most commonly, run-time sub-classing techniques. Also, important is that the mixins and interceptors (i.e. the aspects) can be weaved into any object, immaterial of it’s type, place in a class hierarchy, etc. The fact that this happens at run-time in a non-linear fashion (sort of) creates this air of magic around AOP. Not to mention that AOP has some really weird terminology to describe previously well understood concepts.
Andrea Provaglio also participated in the discussion and made the observation that a style class in CSS is, perhaps, an aspect because it alters the appearance of the HTML element to which the CSS style is applied at run-time. Again, I think that if CSS was explained in the language of AOP, it would probably have taken a longer time to gain wide-spread acceptance. What CSS succeeded in doing was to apply a language set consistently, introducing new terms that could be explained using existing, easily understood terms. Even though certain terms (e.g. class) have different meanings when used in the CSS domain, these terms have a foundation in clearly understood concepts.
From a DDD perspective, the use of ubiquitous language is very apparent and thorough in the domain of AOP (i.e point cuts, join points, introductions, advices, etc.). However, I think that the bridge between the language set in the AOP domain and language set of the patterns domain and object orientation domain, from which AOP is derived, is missing. Let me clarify my point with another question: “Would AOP have gained greater acceptance and understanding if it adopted a ubiquitous language set that transitioned already understood concepts (interceptor, mixin, subclassing, etc.) to introduce the newer terms (point cut, join point, advice, etc.)?”
There are three DDD subtleties lurking here:
- Having a ubiquitous language is not enough; the language set must be easily understood and explain new terms using already understood terms. It’s like mathematics. We prove new theorems based on fundamental laws and the already proven theorems. Because we have confidence and faith in the fundamental laws and proven theorems, we gain confidence in the correctness of the new theorem. This results in the acceptance of the new theorem. Similarly, explaining new concepts in a problem domain using already understood and accepted concepts increases overall understanding.
- The ubiquitous language must aim for simplicity and high readability. If complex concepts are explained in a simple language that is highly readable, it is more likely that the concepts stand a better chance of being understood. Overall, our design and solution for the problem domain will stand a greater chance of acceptance from all stakeholders.
- As we explore and gain further understanding of the domain, our language set will change to introduce new terms, bridges between old and new terms, transitions from retired terms to superceded terms, deprecated terms, etc. This occurs during conversation and natural dialog in an attempt to gain further understanding of the domain. But we need to be aware of these changes. What we are actually doing is refactoring our ubiquitous language set. In DDD, the language of the domain is reflected in code. If we refactor our code, we are refactoring our language set. If we refactor our language set, we are refactoring our code.