Domain-driven and database-driven project for MVC web application

Question

I am expanding / converting an obsolete Web Forms application into a completely new MVC application. Expansion both in terms of technology and in terms of business use. A legacy application is a well-designed database support project (DBDD). So, for example, if you have different types of employees, such as Operator, Supervisor, Store Keeper, etc., and you need to add a new type, you just add several rows to a couple of tables and voila, your user interface automatically has everything to add / update a new employee type. However, the separation of the layers is not so good.

The new project has two main goals

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

I intend to create a new project replacing DBDD with Driven Design (DDD), taking into account the Extensibility requirement. However, the transition from the Driven Design database to Domain Driven Design seems to adversely affect performance requirements if I compare it with the legacy DBDD application. In an outdated application, any data call from the user interface will directly interact with the database, and any data will be returned as a DataReader or (in some cases) DataSet.

Now with a strict DDD call, any data call will be routed through the "Business" and "Data Access" levels. This means that each call will initialize the business object and the data access object. Different types of data may be required on one page of the user interface, and this is a web application on which each page can be requested by several users. In addition, the MVC web application does not have a status; each request will need to initialize business objects and data access objects each time. Thus, it seems that for an MVC independent application, DBDD prefers DDD for performance.

Or is there a way in DDD to achieve both, the extensibility provided by DDD and the performance provided by DBDD?

Answer 1

Have you considered some form of Command Query Seperation where updates pass through a domain model but read as DataReaders? A fully bloated DDD is not always suitable.

Answer 2

“Now with a strict DDD call, any data call will be routed through the Business and Data Access Layer.

I do not believe that this is true, and this, of course, is not practical. I believe this should read:

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

There is nothing that suggests that you cannot directly call the data access level to retrieve all the data needed to be displayed on the screen. This is only when you need to make changes to the data that needs to be called up for your domain model, which is developed based on its behavior. In my opinion, this is a key difference. If you route everything through your domain model, you will have three problems:

• Time - you will need more time to implement the functionality, without any benefits.
• Model Design - Your domain model will be bent in shape to satisfy query requests, not behavior.
• Performance - not because of an additional level, but because you can’t get aggregated data from your model as fast as you can directly from a query. those. consider the total cost of all orders placed for a particular client - it’s much faster to write a request for this than to get all the ordered entities for a client, sort through and summarize.

As Chriseyre2000 mentioned, CQRS aims to solve these exact problems.

Answer 3

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

initialize business object and data access object

Why is “initialization” expensive? What data access mechanisms do you use?

DDDs with long-lived objects stored in a relational database are typically implemented using ORM. Used properly , ORM will have very little, if any, performance impact on most applications. And you can always switch the most performance-sensitive parts of the application to raw SQL if there is a proven bottleneck.

For what it's worth, NHibernate needs to be initialized only after the application starts, after which it uses the same ADO.NET connection pool as your regular data readers. Thus, all this boils down to the correct display, the choice of strategy and the elimination of access errors to classical data, for example, "n + 1 selects".