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 ?

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.

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.

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