Can anybody have good answer when should be database driven development be used and when should domain driven development be used. These both development approach have their importance in their respected areas. But I am not so clear which approach is appropriate in what type of situation. Any recommendation?
As a side-note to mendelt's post, I feel there is a fourth pattern: one that is layered, separates busines logic from persistence and storage, yet uses no "entities", or "busines objects". A half way point, if you will, between Transaction/Action script and DDD.
In a good deal of the systems I've worked on, the persistence layer (repositories) used SqlClient directly and returned datasets to a calling service. The services performed decisions and compiled views which were sent to the user, through the controller. You migth consider the service layer a business model, and you'd be right, but it wasn't a "domain" model in the DDD sense. Still, ALL business logic occured in that one layer, period. Each layer had it's job. The views displayed data, the controllers determined views, the persistence layer handled storage, and the services worked in-between controllers and persistence.
The point is this: DDD is an approach to defining a business through Ul, tests, and code. It is not about entities, value objects and aggregates. Those things are just by-products of the OOP purists approach to DDD.
Just more thoughts for your consideration.