When to use domain driven development and database

问题:

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?

回答1:

First for some background, Martin Fowler actually described three different "patterns" in his book Patterns of Enterprise Arcitecture. Transaction Script, Active Record and Domain Model. DDD uses the domain model pattern for the overall architecture and describes a lot of practices and patterns to implement and design this model.

Transaction script is an architecture where you don't have any layering. The same piece of code reads/writes the database, processes the data and handles the user interface.

Active Record is one step up from that. You split off your UI, your business logic and data layer still live together in active record objects that are modeled after the database.

A domain model decouples the business logic that lives in your model from your data-layer. The model knows nothing about the database.

And now we come to the interesting part:
The cost of this added separation is of course extra work. The benefits are better maintainability and flexibility.
Transaction script is good when you have few or no business rules, you just want to do data-entry and have no verification steps or all the verification is implemented in the database.
Active record adds some flexibility to that. Because you decouple your UI you can for example reuse the layer beneath it between applications, you can easilly add some business rules and verification logic to the business objects. But because these are still tightly coupled to the database changes in the datamodel can be very expensive.
You use a domain model when you want to decouple your business logic from the database. This enables you to handle changing requirements easier. Domain Driven Design is a method to optimally use this added flexibility to implement complex solutions without being tied to a database implementation.

Lots of tooling makes data-driven solutions easier. In the microsoft space it is very easy to visually design websites where all the code lives right behind the web-page. This is a typical transaction script solution and this is great to easilly create simple applications. Ruby on rails has tools that make working with active record objects easier. This might be a reason to go data-driven when you need to develop simpler solutions. For applications where behaviour is more important than data and it's hard to define all the behaviour up front DDD is the way to go.

回答2:

I've asked a similar question: Where do I start designing when using O/R mapping? Objects or database tables?

From the answers I got I would say: Unless you have concrete reason to use database driven development, use domain driven development.

回答3:

Think of it this way.

The problem domain exists forever. Your class definitions will reflect the eternal features of the domain.

The relational database is today's preferred persistence mechanism. At some point, we'll move past this to something "newer", "better", "different". The database design is merely one implementation; it reflects a solution architecture more than the problem domain.

Consequently, it's domain first. Classes reflect the problem domain and the universal truths. Relational database and ORM come second and third. Finally, fill in other stuff around the model.

回答4:

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.

回答5:

For complex business models, I prefer a mix of ActiveRecord and DDD. The domain objects know how to save themselves and data actions are done against a repository (nHibernate can act as a generic repository, if you look at a repository as something that exposes data to the model as a collection). The business logic resides in the domain entities, and even some encapsulation of value types can be accomplished, although only when there is a business need. Some implementations of DDD favor removing all public setters and only modifying entities through methods. I'm not a fan of that implementation unless there is a very good business need.

It seems to me that this implementation gives you the ease of use of ActiveRecord and the business logic encapsulation of DDD.

回答6:

Domain Driven Development is surely the way to go. it makes more sense and adds flexibility.