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?
Does DDD make sense for apps which mostly present data?
architecture;domain driven design;enterprise architecture