Hi guys,

I'm wondering what's your take about where presentation models get dealt with? E.g. screens where we do complex search/filtering then display the result in a very pedantic list of screen-specific representation.
Ideally, presentation models are established in presentation-layer, whereas application-services and repositories produce the domain entities required to constitute the presentation. However, there are data-access implications, e.g. lazy-load.
Hiding stuffs behind application-service, repository etc makes it difficult to make screen-specific projection (from ORM into DTO) to avoid N+1 lazy-loading. E.g., a screen to search customers, which was initially nice and easy until the client ask a change request to add a column to the search-result list: "number of subscriptions the customer has".

It's so tempting to let applicaiton-service (or repository) to deal directly with screen-specific DTO. But application layer is not supposed to deal with DTO or presentation-models. Many purists have always preached the importance of having mappers to translate DTO to application-layer, and that application-layer should only deal with domain objects. I just can't figure out how to maintain data-access optimization this way.

OK, I'm aware of philosophy like CQS that separates query into different bounded context and data-store from usual domain entities. But I haven't bought into this yet. The upkeep cost for logic duplication is IMO enormous, and I can't justify yet to move to that architecture until I know better about it (which would be for another post).

Cheers
Hendry


__._,_.___


__,_._,___