I'm trying to decide the best place to take care of presentation logic. I've separated out my Read queries (CQRS) with each method querying and generating a DTO for my View. But my Views are simply templates with variables scattered about that will come from the DTO. They don't have any logic in them.
Say I want to do some things like reformatting how the date looks, and turning flags into actual descriptive words, or adding little conditions on what is displayed depending on what is queried from the database, and so on. I'm thinking to put this logic in with each query, and to not worry about being too DRY (I find that in some cases if you DRY too much then you could be making things hard to change in that you have to check each dependency or hope your unit tests hold up). I may use some "helpers" here and there to do formatting that I find I keep doing, but I don't see the need to add a whole other "presentation layer". So presentation logic would reside with each query and go into the returned DTO, to be dropped right into a View. This would keep the Read side of CQRS super thin, and makes sense in that each View corresponds to a Read query. But I'm also concerned in that some of this presentation logic would be very specific to the domain. A new developer coming on board would need to look at other queries and repeat the same formatting techniques, as opposed to just throwing the data out there straight from a raw query.
Is this the sound approach, or is there another approach used in DDD/CQRS? I'm having trouble finding any guidance from CQRS research I've done. Note: I happen to be using PHP/MySQL, but I imagine this question is language agnostic.
I think the most important part to understand about CQRS is that it doesn't have to be complicated. In fact, for the read side of things go for the simplest solution that will work and be maintainable. If all you need is a SELECT statement from a view to bind to a grid, why make a bunch of layers, DTO's, and web services? Is that adding any value to the business? However if there is a legitimate reason to add a layer to the equation then you may do so, and usually DTOs are a good way to communicate between those layers.
Your system may call for different query strategies depending on the use case at hand, so this doesn't have to be a one size fits all approach. Performance should always be one of your first concerns, so get the data as close to the consuming presentation code as possible and only add complexity when truly needed.
Some might say this is not loosely coupled if the presentation layer is reading directly from the database. However, just because you have many layers between 2 things, doesn't make them loosely coupled. In fact, it may be the same amount of coupling, but now you've added a maintenance headache since you have to touch 10 places every time a field is added.
Focus more on your command side, and do whatever feels practical for the read side.