Well, that very much depends on what exactly you mean by domain model. DDD certainly does not advocate putting all your business logic on (persistent) domain objects (entities), but explicitly acknowledges the notion of a service.
This a-domain-object-is-a-web-page-is-a-database-table approach might work well with relatively small applications. However, I have some difficulties to see this work with complex domain object models (as in lots of classes, lots of associations, non-trivial interactions and constraints), which is exactly the kind of applications where you'd favor a domain model over alternate approaches (eg transaction script, see Fowler's PoEEA).
Kind regards,
Oliver |