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.
