Sunday Morning on InfoQ, Part 2

Well it is still Sunday morning, and the weather is still bad … so I am staying on InfoQ

I watched an interview with Jimmy Nillson on Domain Driven Design

The interview is about Domain Driven Design (DDD) (see also my presentation).
If you have read DDD of Eric Evans and ADDDAP of Jimmy Nillson, the Interview does not offer much interesting content.

However at the end of the interview Jimmy talks about MDA in relation to DDD. He states that in DDD the code is the model while in MDA the model defines the code. At the time being the two notions stand in conflict with each other. Jimmy states that this does not have to be, but with the current state of the tools and implementations of MDA (“executable UML”) the conflict exists.

This reflects also my current opinion. I basically think it is not a good idea to use code-generation in your business-logic. The business-logic is the the core of your application. It is the value that your application offers to the user, its where the knowledge of the domain is buried where and all the insights extracted from analysis and design are applied.

Code-generation cannot help you with creating this business-logic, because the knowhow and the insights about the domain cannot be generated automatically.

Code-generation can only help you with infrastructural concerns like persistence, gui-binding, distribution … but not with implementing the core business-logic.

So again it is important to apply strict Separation of Concerns, so that the core business-logic can be developed independently of infrastructural problems. The more the infrastructural problems leak into the business logic, the more moves the concrete implementation of the business-logic away from the core-domain. Then again people will think that code-generation solves their problem. But in reality this would only be fighting symptoms of a bad architecture and not seizing the root of the problem, which is leaking concerns.