Domain Driven Design vs Database Driven Design for an MVC Web application

Question

I am expanding/converting a legacy Web Forms application into a totally new MVC application. The expansion is both in terms of technology as well as business use case. The legacy application is a well done Database Driven Design (DBDD). So for e.g. if you have different types of Employees like Operator, Supervisor, Store Keeper etc and you need to add a new type, you just go and add some rows in a couple of tables and voila, your UI automatically has everything to add/update the new type of Employee. However the seperation of layers is not so good.

The new project has two primary goals

• Extensibility (for currently and future pipeline requirements)
• Performance

I intend to create the new project replacing the Database Driven Design (DBDD) with a Domain Driven Design (DDD) keeping the Extensibility requirement in mind. However moving from a Database Driven Design to Domain Driven Design seems to inversely impact the Performance requirement if I compare it to the performance of the legacy DBDD application. In the legacy application any call for data from the UI would directly interact with the Database and any data would be returned in form of a DataReader or (in some cases) a DataSet.

Now with a strict DDD in place any call for data will be routed through the Business layer and the Data Access layer. This would mean each call would initialize a Business Object and a Data Access Object. A single UI page could need different types of data and this being a Web application each page could be requested by multiple users. Also a MVC Web application being stateless, each request would need initializing the business objects and data access objects each and every time. So it seems for an MVC stateless application the DBDD is preferrable to DDD for performance.

Or there a way in DDD to achieve both, Extensibility that DDD provides and performance that DBDD provides ?

Formate

Starred as an interesting question because it takes the mechanics behind the various designs so literally. Very often, these discussions are too abstract to be useful. This one is very direct. I am keen to see what the answers are (I myself have no idea). – Claustral

I have a couple of questions before I start thinking: 1. What exactly is performance requirement? How quick should the application respond. Should all queries be responded in 1 sec OR 0.5 sec for fetching data and 1 sec for updates? 2. Do you already have some metrics for current application and how much slower would an MVC based one would work? – Garda

I have metrics for current application Database operations. Except for the reporting which can have complicated and data heavy operations and may take minutes, the CRUD takes less than a sec while maximum data fetching operations occur within 2 - 3 seconds at the database level. How much slower will be the MVC application, the question is all about – Formate

It's the communication with a MVC application that is stateless. You can (and should) cache whatever you can. – Jeannettajeannette

Answer 1

Have you considered some form of Command Query Seperation where the updates are through the domain model yet reads come as DataReaders? Full blown DDD is not always appropriate.

Jeannettajeannette

+ 1 for recommending CQRS. Although I have to say that using CQRS doesn't mean that you are no longer using 'full blown DDD'. Quite the contrary. Projecting DTOs/View Models from your domain aggregates as opposed to projecting them direct from the database doesn't detract from the level of DDD you are practicing. Doing the former just makes life hard for yourself and requires a layer of mapping from objects that are (or should be) designed on the invariants they enforce in transactions. The latter, to me, is just the practical/sensible way. – Sync

This doesn't solve bulk write queries. And it also doesn't solve the problem that sometimes you need to work with IDs only, and don't need to hydrate everything (for performance). You can add rules to each entity, but you are bound to get write operations that are going to cover writing data that pertains to multiple entities (doesn't matter if they are aggregates) and you'll need to duplicate those rules because you are avoiding looping through each entity to apply it's rules individually (defeats purpose of DDD). – Popover

Here's a good article that addresses the problem I mention. I don't know if the solution given sufficiently resolves the problem though. It's a tough subject. CQRS helps, but we still have performance issues on the write side to deal with as well. – Popover

Answer 2

"Now with a strict DDD in place any call for data will be routed through the Business layer and the Data Access layer."

I don't believe this is true, and it's certainly not practical. I believe this should read:

Now with strict DDD in place, any call for a transaction will be routed through the business layer and the data access layer.

There is nothing that says you can't call the data access layer directly in order to fetch whatever data you need to display on the screen. It is only when you need to amend data that you need to invoke your domain model that is designed based on its behavior. In my opinion this is a key distinction. If you route everything through your domain model you will have three problems:

1. Time - it'll take you MUCH longer to implement functionality, for no benefit.
2. Model Design - your domain model will be bent out of shape in order to meet the needs querying rather than behavior.
3. Performance - not because of an extra layer, but because you wont be able to get the aggregated data from your model as quickly as you can directly from a query. i.e. Consider the total value of all orders placed for a particular customer - its much faster to write a query for this than to fetch all order entities for the customer, iterate over and sum.

As Chriseyre2000 has mentioned, CQRS aims at solving these exact issues.

Sync

Answer 3

Using DDD should not have significant performance implications in your scenario. What you worried about seems more like a data access issue. You refer to it as

initialize a Business Object and a Data Access Object

Why is 'initializing' expensive? What data access mechanisms are you using?

DDD with long-lived objects stored in a relational database is usually implemented with ORM. If used properly, ORM will have very little, if any, impact on performance for most applications. And you can always switch back the most performance-sensitive parts of the app to raw SQL if there is a proven bottleneck.

For what's it worth, NHibernate only needs to be initialized once on application startup, after that it uses the same ADO.NET connection pool as your regular data readers. So it all boils down to a proper mapping, fetching strategy and avoiding classic data access mistakes like 'n+1 selects'.

Episiotomy