1-1 start/2007-01-14/1

You say that the business logic is "anything related with the problem itself", like "how many objects Y object X can have, or method M can only be accessed in the context C should be here". Then you say that "ADM is a model which has the objects and the relations but lacks the business logic".

My first question is very simple: if the model lacks the business logic, then it doesn't have anything related with the problem itself (I am just using your previous definition). But aren't the relations and the objects related with the problem? I think that your article leaves this concepts very unclear.

Also, you say that "So when you need, for example, to change some sort of behaviour you just need to change the code inside the object and it's most of the time self contained.". My question is to what extent can you claim that it is most of the time self contained. I would say it is very common to have the behaviour of certain objects dependent on other different objects (and by very common, I really mean the general case).

Finally, you say that "Some people might think design doesn't really matter, (...)" and I have to agree with you, except that I don't know anyone who claims that it doesn't matter

As a final remark, let me just say that I wasn't able to completely understand the article. I think the problems were some undefined concepts that I don't know and I'm also confused about the context of DDD -- when can I use it?

Thanks for the article, and I hope I can get some answers and comments from other users as well.

Cheers, Joao