Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Published on
Using Domain Driven Design and Model Driven Development together to create a lean architecture
It's true, that this approach works just a well with a text (DSL) based approach to describing the domain.
The more complex the domain, the more I believe that Visual models benefit the description of the domain. I've experienced this on quite a few projects already. It's easier to see the complex interrelations between aggregates in a visual model, than in a textual hierarchical description. Even though it might sound odd, even the fairly 'ugly' UML class diagrams have worked very well with non-technical personnel and given a good enough foundation for communication.
Using the code directly as a model is an idea that I've used quite a lot too, but it's IMO less suited for domain and service models. The more expressive the language (XText/Ruby/Groovy/Scala/etc.) the better, when it comes to using Code as the Model :)
We're in the process of open sourcing the tool, and during that transition a renaming from xxxxMDSD would definitely be in place :)
Looks like as opposed to other tools you go much further than code templates and use smarter meta-model-based wizards to generate the code for each pattern, and I think this is a good thing!
I'm still not fan of the code generation part of MDD, I prefer using code directly as a model, but I'm glad to see tools getting much better like Tiger MDSD ('MDSD' hard to remember to me by the way). Cheers