When to use domain driven development and database driven development?

Question

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?

Answer 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.

Answer 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.

Answer 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.

Answer 4

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