问题
I'm trying to create a reporting/analysis web app that will use MVC3, EF and DDD approach. I'm havign a hard time to come up with entities or object classes for aggregated tables on existing database. For example, I have Orders and OrderLine as an aggregate and Customers as Entity. This three objects can be modeled using DDD approach but what if I want to have an OrdersAggregate Table which will contatins all the details like customer name, payment type, etc.
Should I create an object class here which contain the properties of customername, payment type, etc. or let EF create his sql query and join related tables? I'm worrying about performance here and this will be deploed on a cloud and a huge volume of transactions awaits.
Any suggestions?
回答1:
You can utilize CQRS and here in some aspects to take the benefit of separating read model from write.
Dont have to implement the entire architecture, just separate the read from write model and services, this make the read model send customized DTOs flat for rading and analysis purposes, and a strong domain model on the other hand in the write model for business logic handling.
check this and this example
回答2:
My experience is that DDD is not suitable for doing reporting, statistics etc. Some experts in like Jimmy Nilsson tells you to bypass your domain with regular dataacces. If you just think about it, there is not much domain logic in presenting the data. It just seems like an overhead in doing layers and DDD style with ORM, repositories, aggregateroots etc just for view data.
Just a personal opinion. /Good Luck and best regards Magnus
回答3:
My suggestion is to create a DTO class for this purpose, and fill using a dataset returned from a SQL command (hand-made) with your joins and relationships.
Is only a suggestion, because I used this approach to a similar problem.
来源：https://stackoverflow.com/questions/7831763/ddd-reporting-scenarios