@49833977598de9524fa85cacb93a42ce:disqus

@147381277b8f7d05eb3a93c5e8fb0439:disqus

I just wanted to make a reservation. I’m agnostico ActiveRecord in the extent that the Model Object are not responsible for persisting themselves. So the DomainServer must orchestrate them and “update them state via Repository’s.

I think that we can’t focus only in (OO) (idealling) modelling the Entity’s (Classes), and otherhand focus only in Data (Relational DB) Modelling. Bcz invariably we’ll must make the OR-mapping. So we have to search the Model that best reflects/abstracts the reallity (Business|Domain) and the Design that best concil OO and Data Modeling.

As you mention I haven’t seen DDD done when there wasn’t a domain model in use as well.

So in a way there are almost two questions I was pondering – what are the alternatives to DDD and what are the alternative to using the domain model? It would be interesting to hear your thoughts on the former.

You’ve presented as alternatives techniques that are at the same level as the Domain Model pattern, not Domain-Driven Design.

It is very hard to have DDD without the Domain Model pattern but you don’t have to use DDD just because you have a Domain Model. DDD is about using business language in the software constructs, Domain Model is just about having proper objects (and not just functions and data structures) as the business logic holders.

So, in the end of the day the answer to your question would be ‘no’, but not just because you could use transaction scripts or table gateways but because you could have a Domain Model that’s not designed after DDD principles.

cheers

Using Castle ActiveRecord, and so using attributes to control persistence, and binding those “domain” objects directly to the GUI is incredibly simple. Even if your DB and domain don’t match it can work as there is some flexibility there.

Obviously if its a shared DB, or you don’t control the DB, then it is more work but even then you can bridge the gap between relational and domain relatively easy when the problem domain is relatively small and/or simple. In such cases you can sacrifice some domain model quality to make the mapping possible/easier.

However if you want to do DDD “properly” you really have to use not only the patterns but the ideas including the analysis/design. That adds a lot of work on its own, work thats very worthwhile but not necessarily needed in all cases.

So I actually think that the core patterns (factory/service/aggregate/specification/repository/entity/value object) can be used in many more cases than the concepts.

Re: the silver bullet idea…I just meant that it seemed (in the discussion at the conference) that it could be applied to all situations and other approaches were ‘less worthy’. Of course that may just be my perception but I thought I’d put it out there.

I think you must distinguish between when there is a good technical argument and a good social argument. Obviously the domain of your app must play some part in your decision and not just whether or not you have buy in.

Likewise you could have a very table oriented way to storing your data, but that does not mean it is the way you should be storing your data.

Figure out what are the parameters of your app, and what are the capabilities of the people you will be working with.

Don’t base it solely on whether you have buy in or whether it is already being done another way. as you suggest above. There are objective pointers to use.

and by the way, can people stop suggesting that anything was ever called a silver bullet by anyone. Can we just assume that anyone who does suggest that anything is a silver bullet is too stupid to merit a response? Then we could concentrate on more worthy discussions.