repository pattern - Can't help but see Domain entities as wasteful. Why? -
i've got question on mind has been stirring months i've read ddd, patterns , many other topics of application architecture. i'm going frame in terms of mvc web application question is, i'm sure, broader. , this: does adherence domain entities create rigidity , inefficiency in application?
the ddd approach makes complete sense managing business logic of application , way of working stakeholders. me falls apart in context of multi-tiered application. namely there few scenarios when view needs data of entity or when 2 repositories have all. in , of that's not bad means make multiple queries returning bunch of properties don't need few do. , once done extraneous information either gets passed view or there overhead of discarding, merging , mapping data dto or view model. have need generate lot of reports , problem seems magnified there. each requires unique slicing or aggregating of information sql can repositories can't they're expected return full entities. seems wasteful, honestly, , don't want pound database , generate unneeded network traffic on matter of principle. questions this should repository layer return data-transfer-objects (dto)? seems i'm not 1 struggle question. what's answer limitations seems impose?
thanks new , confounded ddd-er.
what's real problem here? processing business rules , querying data 2 different concerns. realization leads cqrs - command-query responsibility segregation. what's that? don't use same model both tasks: domain model behavior, performing business processes, handling command. , there separate reporting model used display. in general, can contain table per view. these tables contains relevant information can rid of dto, automapper, etc.
how these 2 models synchronize? can done in many ways:
- reporting model can built on top of database views
- database replication
- domain model can issue events containing information each change , can handled denormalizers updating proper tables in reporting model
Comments
Post a Comment