I'm responsible for designing a dashboard and data manipulation front-end for a sale transaction database and am not quite sure what type of architecture to use. The database is populated by an external ETL system.

The required functionality for my app is very simple; it must display a few alerts of exception conditions it detects in the database, present a few charts and tables, and some basic CRUD operations on a few tables. There is very little behaviour required; the business will use the app to find out about things, rather than do things.

Given this lack of behaviour, does a DDD approach make sense? My current thinking is to create database views to encapsulate the queries my app will need, wrap these views up with an ORM, and have the web controller query the repository layer to get an ORM object with the data it needs. This ORM object would then be passed into the presentation layer.

This does of course create strong coupling between the database, the ORM framework, the presentation layer, and my logic. A reasonable amount of what logic there is would wind up in the database views.

Can I make a DDD approach work for this kind of app, or is there a more suitable way of doing it?

2 Answers 2


If there is little behavior a DDD approach can be overkill, its your application its totally data-centric and with little logic probably the coupled solution can be a good decision. I don't know what technology are you planning to use, for a system like that i probably choose a framework like rails, grails or django an use ActiveRecord pattern.

The worst with this coupled systems is when you ends up unconsciously with a system like that, but if your take a conscious decisions based in your knowledge about the problem, things like DDD or ORM's are only tools in your toolbox and you pick up the right one for the project at hand.

  • Upvoted - Note the subtitle to the Blue Book: Tackling Complexity in the Heart of Software. If the project isn't complex (and never has a 10% possibility of becoming complex), excessive modelling of any type will not give you ROI. Kind of like hiring an architect for the Doghouse your'e building behind the garage.
    – FastAl
    Feb 17, 2014 at 3:09
  • DDD is overkill for most applications that do have behavior too May 8, 2018 at 12:39

Given this lack of behaviour, does a DDD approach make sense?

Is the problem that you are trying to solve part of the core of the business? Do you derive a competitive advantage here?

If it really is "just a query tool," then no. If maintaining the quality and integrity of the data isn't critical to success, then no.

DDD is too expensive a hammer for small incremental gains.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.