Sharing ReadModel generation logic

[Fredrik Skeel Løkke]

Hi

In our team there's some concern to the seemingly duplication of code when generating read models. 

The team is in full control of about 10 services that publishes and subscribes to events through eventstore (geteventstore.com).

At the moment there is some duplication of code generating in-memory readmodels. Event schemas are shared through binaries.

Why not share some code also?

My main worry regarding sharing code is mainly: 

Instead of a service picking just the data it needs, it will have dependencies on a few big readmodels. Which will change more often than the event schemas.

Any input will be appreciated.

[Peter Hageus]

’It depends’ J

 

I struggle with this as well, trying to tidy up a big code base. Either you query the owner of the data (tight coupling), or keep a local copy/cache/whatever. (duplication of data and more code). If you go for the local copy, ask yourself if the readmodel really represents the same thing in each service/context. If it does, hosting the same code in different contexts should not be a problem imho. Oth, since you say they are big, maybe they try to cater to many needs? In that case I’d split them up…

 

/Peter

--
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.

[Fredrik Skeel Løkke]

Thank you for the input Peter.

[Kijana Woodard]

If the services are partitioned by "noun", there probably is quite a bit of unseemly duplication.

If they are partitioned by business capability, the duplication is warranted because, as Peter pointed out, they're different things with the same name. A Sales Order and a Shipping Order can be very different.

[Amit Choudhary]

I agreed with @Kijana thoughts. Also beware of Fallacy of Reuse. Sometimes you think repeatable code can be shared or reused without having a second thought that business could drive changes specific to one thing in that "reusable" piece. ... and this is where the problems would start showing up. You'll find your self in a situation where you might have to separate that "reusable" piece again.

Amit Choudhary
+91-9560002093
www.twitter.com/vendettamit

[Kijana Woodard]

Or worse, separate it through if statements obscuring the true structure.