Construct DTOs from ARs or plain SQL (with state-based persistence)?

[Alexandre Potvin Latreille]

It's the first time that we implement a domain model and we are facing situations where there's a clear mismatch between data needed to be shown on the UI and the shape of our Aggregate Roots.

Event though we are not using CQRS/ES at this time, would it still be more appropriate to express queries in plain SQL and map result sets to DTOs rather than letting queries affect the shape of our ARs?

[Alexandre Potvin Latreille]

To add a bit more details, we broke the "Reference other ARs by ID" rule many times just to make DTO construction easier and we also relied on Hibernate formulas. This all feels very wrong to me and I wanted to know if others ever used a CQRS-like approach (using the write database) in the sense that they bypassed their domain model entirely for queries in favor of querying the database directly?

[João Bragança]

> in the sense that they bypassed their domain model entirely for queries in favor of querying the database directly?

This should be the default approach otherwise there is no point in doing CQRS.

On Tue, Jul 7, 2015 at 4:57 PM, Alexandre Potvin Latreille <alexandre.pot...@gmail.com> wrote:

To add a bit more details, we broke the "Reference other ARs by ID" rule many times just to make DTO construction easier and we also relied on Hibernate formulas. This all feels very wrong to me and I wanted to know if others ever used a CQRS-like approach (using the write database) in the sense that they bypassed their domain model entirely for queries in favor of querying the database directly?

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sent from my regular computer

http://twitter.com/thefringeninja

http://www.thefringeninja.com/

[Alexandre Potvin Latreille]

@João Bragança I understand this, however the fact is that we have no dedicated read model and we are performing state-based persistence (not EventSourcing). In these conditions, I'm wondering if we would be better off by tweaking the domain model or segregate read and writes operations even though we have no dedicated read database.

[João Bragança]

It's OK not to have a separate database at first. You separate the models first (even if they point to the same database), which then frees you up to re-implement one or both of them later if you need to.

On Tue, Jul 7, 2015 at 5:50 PM, Alexandre Potvin Latreille <alexandre.pot...@gmail.com> wrote:

@João Bragança I understand this, however the fact is that we have no dedicated read model and we are performing state-based persistence (not EventSourcing). In these conditions, I'm wondering if we would be better off by tweaking the domain model or segregate read and writes operations even though we have no dedicated read database.

--

You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kijana Woodard]

Just to be sure....

Both the "data needed to be shown on the UI and the shape of our Aggregate Roots" are orthogonal to data persistence. You're going to be coercing the persisted model into the read and write models. 

You may choose the read or the write shape to also be the persistence shape, but that's a choice not a necessity.

Example: Aggregate Root hydrated from Events [ES] vs a document vs rdbms.

[Alexandre Potvin Latreille]

@Kijana Woodard  Yes, I get your point, however if the domain is used to build DTOs, it also means that it has to be shaped as such. Since we are using Hibernate and state-based persistence in a rdbms, it's easy to fall for adding unnecessary relationships between aggregates to fulfill those query needs.

With ES-based persistence I guess we wouldn't be asking the question, however when using Hibernate you kind of have the choice of writing HQL queries and tweak aggregates for query needs (seems to be what most people do) or build queries off the database directly and let the domain model evolve independently.

[Raoul Duke]

so, should I see this as reinforcing my long-standing,
experience-based, general dislike/distrust of ORMs and especially
Hibernate? :-)

[Konrad Garus]

You still can query the Hibernate-persisted model with views or raw
SQL. Keep the domain clean, use something slightly different for
querying.

Another approach is to emit events (not ES) when something changes in
domain, and update some read model from them on the fly. Or implement
the ol' good ETL.

Here's an excellent talk from Sandro Mancuso where he touches on this.
Something more of a pragmatic hybrid than full-blown DDD/CQRS/ES.
Link: https://vimeo.com/101106002

> --
> You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--

Konrad Garus

[Kijana Woodard]

"...however when using Hibernate you kind of have the choice of writing HQL queries and tweak aggregates for query needs..."

Notice you have yet another model involved: the Hibernate model. That alone doesn't horrify me because if you wrote raw SQL, you'd have to keep that in line with persisted data structures.

This is the dilemma of any shared model. It's being pulled in multiple directions. If you start tweaking things to the benefit of one thing and the detriment of another, so be it. Just be conscious about that decision. Mostly people are just hacking to clear "Story Tasks" and have no idea they just made the situation measurably worse for some scenario....until that pager goes off at 2am.

"...however if the domain is used to build DTOs..."

I would reject this line of activity.

"...build queries off the database directly..."

This. Or a separate hibernate model [never used [n]hibernate, so not aware of any nuances].

[Colin Yates]

Hibernate is just a tool. The downfall comes when you have a ‘domain model’ mapped with Hibernate and then fall into the same old trap of having one model used to articulate business processes and queries.

I see nothing wrong with using Hibernate for your domain model, or your read model or both. The point is that your domain model _isn’t_ also the query model.

[Raoul Duke]

> I see nothing wrong with using Hibernate for your domain model, or your read model or both. The point is that your domain model _isn’t_ also the query model.

ah, right! thanks.

[Ben Kloosterman]

Even for non CQRS i think its often a good idea for queries too bypass the logic ( unless you have really good OO guys , most groups have a lot of CRUD guys) .   However you still want some sort of query repository to organize these so they can be reused and managed  - what you definitely dont want to see if queries being built in GUI (esp code behind)   , API or the Facade  . 

Regards,

Ben

On Wed, Jul 8, 2015 at 1:50 AM, Alexandre Potvin Latreille <alexandre.pot...@gmail.com> wrote:

@João Bragança I understand this, however the fact is that we have no dedicated read model and we are performing state-based persistence (not EventSourcing). In these conditions, I'm wondering if we would be better off by tweaking the domain model or segregate read and writes operations even though we have no dedicated read database.

--

[Freek Paans]

How is that non CQRS?

[Alexandre Potvin Latreille]

Thanks for all your inputs! It reassured me that bypassing the domain model would still be beneficial without a full-fledged CQRS/ES solution in place. The only thing that annoys me a bit is that some domain calculations will probably have to be made in the query side, but I guess we can't easily fight it...

[Ben Kloosterman]

CQS maybe  but generally CQRS etc use DDD techniques.

Ben

[Colin Yates]

CQRS is sympathetic with DDD but it isn’t mandatory: http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/

[Johanna Belanger]

On Wednesday, July 8, 2015 at 8:55:18 PM UTC-7, Alexandre Potvin Latreille wrote:

Thanks for all your inputs! It reassured me that bypassing the domain model would still be beneficial without a full-fledged CQRS/ES solution in place. The only thing that annoys me a bit is that some domain calculations will probably have to be made in the query side, but I guess we can't easily fight it...

I've got quite a lot of calculations like this too. I tend not to use typical read side tools, like SQL or reporting tools to do them. I put them in domain-style code and pass the source data in and the calculated data out to the read model. Sometimes I've found the calculated data actually has a lifecycle and an identity and it's become an aggregate in it's own right.