6

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?

Improve this question

2 Answers 2

Reset to default
5

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.

Improve this answer
2
  • 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. Commented Feb 17, 2014 at 3:09
  • DDD is overkill for most applications that do have behavior too Commented May 8, 2018 at 12:39
1

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.