Menu
I found DDD being natural if I am working on a operational/transactional type of application. However I am always stucked in a reasonable way to handle reporting type of functions.
The reporting I am talking on is not bound to report generation, but also functions that perform comparatively complicated queries. (like, giving the summary of all orders that a trader did, or display the account summary for trading accounts having certain stock, etc). They can be simply some query or supporting function that is used together with those operational function.
For such functions, it is quite natural if we can perform join in SQL (or whatever query language), get the columns we are interested, and return the massaged result set. However, it seems such way not going that well with DDD: we need a extra special repository or having existing most-related repository returning a special "entity/value object" (which is the specialized resultset). These kind of special "entities" is not having any domain meaning in fact.
If we want to make use of the meaningful domain layer, that may creates a lot of extra lookups from different repository, plus a lot of aggregation work in the domain or service layer, which will easily cause horrible performance degrade.
I have also thought of having another "path" for these kind of function, which doesn't go through the "DDD path", having its own way to get the report data from DB, compose the results for display. However it is going to make the application unnecessarily complicated, and even worse, we provided an extra path so that developers that is more used to traditional DB-oriented development may tends to use this path even it is not appropriate.
I thought such situation is quite common (normally a big system will not contains operational but also reporting and enquiry functions), I would want to know how people is dealing with it?
801
Domain-Driven Design(DDD) is a collection of principles and patterns that help developers craft elegant object systems. Properly applied it can lead to software abstractions called domain models. These models encapsulate complex business logic, closing the gap between business reality and code.
The domain-driven approach is here to solve the complexity of software development. On the other hand, you can use emergent design when the challenge is simple. However, when your application is complex, the complexity will only grow, and so will your problems. Domain-driven design bases on the business domain.
Domain Driven Design (DDD) has recently gained additional popularity, as evidenced by new books, conference talks, and even complete conferences dedicated to it), and lots of trainings – including some by our very own colleagues here at INNOQ.
DDD focuses on three core principles: Focus on the core domain and domain logic . Base complex designs on models of the domain . Constantly collaborate with domain experts , in order to improve the application model and resolve any emerging domain -related issues.
In terms of DDD Reporting in most cases is a separate Bounded Context and a supporting subdomain where domain-driven design would be overkill. Remember the most important concept of DDD: Focus your modelling efforts on the Core Domain and implement everything else using the simplest possible solution.
141
We recently got into using DDD for system development. I had the same concerns as yours but eventually settled for Command Query Responsibility Segregation (CQRS) [Fowler, Young, Dahan]. While it is requires "the db path" for querying, I do not feel at all that it becomes tempting to do direct to DB for Commands (those that alter domain state). The separation is very clear - commands go through the domain, Queries go direct to DB.
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
