I am currently working on a project where we use a framework that combines code generation and ORM together with UML to develop software. Methods are added to UML classes and are generated into partial classes where "stuff happens". For example, an UML class "Content" could have the method DeleteFromFileSystem(void). Which could be implemented like this:

public partial class Content
    public void DeleteFromFileSystem()

All methods are designed like this. Everything happens in these gargantuan logic-bomb domain classes.

Is this how MDA or DDD or similar usually is done? For now my impression of MDA/DDD (which this has been called by higherups) is that it severely stunts my productivity (everything must be done The Way) and that it hinders maintenance work since all logic are roped, entrenched, interspersed into the mentioned gargantuan bombs.

Please refrain from interpreting this as a rant - I am merely curious if this is typical MDA or some sort of extreme MDA


Concerning the example above, in my opinion Content shouldn't handle deleting itself as such. What if we change from local storage to Amazon S3, in that case we would have to reimplement this functionality scattered over multiple places instead of one single interface which we can provide a second implementation for.

4 Answers 4


DDD does not require you to have a class handle it's own storage, in fact DDD has the concept of a repository to handle storage. What you're higher ups are doing is having you implement Active Record, and tieing the implementation to the class, rather then hiding it from the class.


Yes some teams model down to the attribute level and provide detailed method signatures. I do not really follow the part about the gargantuan logic bomb; is there logic put into the domain classes that should not be there? The example you provide doesn't seem inappropriate.

  • Well, I'm very accustomed to programming against interfaces - In my opinion, Content shouldn't preferably be coupled against specific file IO, and a heap of other things (since Content have other methods which perform wildly different things). Perhaps if logic was refactored into separate interfaces which was then implemented externally decoupling would be more satisfactory, but the framework we use doesn't support DI, and after all, then we wouldn't need to specify methods in UML anyway. Maybe this is just a quirk of MDA?
    – Max
    Commented Jun 8, 2011 at 17:01

You don't need MDA for that kind of UML class diagram code generation. Live code and model synchronization is for me more appropriate. MDA is more a kind of modeling a higher level of abstraction and then code generation. The code is just a top down push. Once generated the code has no more relation with the model and it is impossible to go backward. Live code and model synchronization is easier and better than MDA.


I think this is a problem with the way your tools generate code. If I understand you right, you moan about the fact that the tools creates "partial class" source files for each and every method (instead of one source file per class). I agree that this is rather stupid and makes the result hard to use and maintain, but this is not typical for MDA or DDD. In fact, a tool could not do that in other languages, e.g. Java, that do not allow "partial class" source files.

  • Well, see my comment on Jeremys answer if you havn't already. I definately don't like the tool we currently use, but I wanted to find out if I simply have an aversion to the typical implementation of MDA or just this one tool.
    – Max
    Commented Jun 10, 2011 at 9:46
  • In general I'd say yes, in MDA you declare every method and attribute in the model, because otherwise the model cannot drive the architecture.
    – user281377
    Commented Jun 10, 2011 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.