The perception that people have when they hear the term 'SOFTWARE ARCHITECTURE' seems to cover a range of definitions, this is even obvious in job Ads.
Almost no two descriptions match, requiring different sort of skills, some more technically demanding and others leadership focused, and so on.
In turn the architectural design methodologies that are offered, try to solve different problems.
While researching about MDA, and reading a few books and articles, it seemed it is a way of designing a system, and has less to do with meeting the quality attributes along with functional requirements of a software.
It is about creating a model of the system in an abstract, platform ignorant way( Platform Independent Model, or PIM), possibly using a DSL(Domain Specific Language).
Models have levels (M1, M2,..) each lower model has more details added to it, this can be more business rules or more technical details (in memory call, remote call, database type, platform,..).
Transformers are in charge of creating the lower level models form the higher level model, injecting more details, getting closer from abstract to concrete.
What seems to be missing is meeting the quality attributes.
Of course MDA does not stop you from achieving them, however it does not provide any guidelines to achieve this.
CONCLUSION:
Having in mind that design and architecture overlap,
MDA seems to be more of about design than architecture. It does not give you with guidelines about how to achieve quality attributes. It focuses on models, model generators,... .
However, this claim, might be confusing, if we do not agree on a definition of 'SOFTWARE ARCHITECTURE'.
You can find SEI's definition of software architecture and a few more here.
Developers speak BIT, domain experts speak money, policy, rules.
Developers use their own language to communicate the technical related concepts and stories. They talk about
booleans, servers, process, asynchronous calls, ... .
Domain experts have limited or no understanding of this language, however they have
a domain knowledge expressed through their own domain language. They talk about invoices, cargo, shipping, fees, ... .
The problem arises when these two worlds need to communicate, a translation is needed.
To compensate for this deficiency, what usually happens is that a developer from the technical team learns the language of the domain experts (well, as good as he can), which is not an ideal situation, and acts and a translator.
Chain of translation show here:
Developer <-> Bilingual developer(s) <-> domain experts.
A very basic example, even a word can matter : recently I was working on a IPTV web project using the third party tool for reporting video consumption attributes.
The word 'BUFFERING', created confusion. And wasted a week.
For them buffering meant, player run out of data so it cannot play anymore, to us it meant downloading the video stream, irrelevant of the playback status.
A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design.
The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of a software project). And even the same person uses different language in speech and in writing, so that the most incisive expressions of the domain often emerge in a transient form that is never captured in the code or even in writing.
Translation blunts communication and makes knowledge crunching anemic.
Yet none of these dialects can be a common language because none serves all needs.
Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and especially speech.
Iron out difficulties by experimenting with alternative expressions, which reflect alternative models. Then refactor the code, renaming classes, methods, and modules to conform to the new model. Resolve confusion over terms in conversation, in just the way we come to agree on the meaning of ordinary words.
Recognise that a change in the UBIQUITOUS LANGUAGE is a change to the model.
Domain experts should object to terms or structures that are awkward or inadequate to
convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.
Also using this language, when modelling the domain, helps developer to express the the wisdom and concepts of the domain, in a clear way, in the code.
Some excerpts taken from DOMAIN DRIVEN DESIGN, BY ERIC EVANS.
