Is defining every method/state per object in a series of UML diagrams representative of MDA in general?

Question

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()
    {
        File.Delete(...);
    }
}

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

UPDATE

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.