Keeping bounded contexts autonomous

[sherifsa...@gmail.com]

In an Event Driven Architecture, What is the proper way to cache the data from other services/bounded contexts so that each service is autonomous?

For example, I have a ProdutCatalogue bounded context and Sales bounded context. Sales might at some point need data from ProductCatalogue and to encourage one way communication Sales will have a cached copy of the data it needs from ProductCatalogue. The cache will be updated using Domain events whenever a change happens in ProductCatalogue.

My questions:
1- Where do you cache the data? inside the service/bounded context? dedicated service?
2- Should the event have the data required to update the cache? or should I just issue a new “getAllProducts()” on the ProductCatalogue to renew the whole cache every time?
3- In what form do I keep the cache? in a form ready for consumption? raw data that is returned from the service? (the ProductCatalogue service may expose on a getAllProducts() method that return extra data that I’m not interested in)

In summary I'm looking for best practices to keep my services autonomous using cached data.

I'm also assuming for simplicity that each bounded context maps to a single service.

[Kijana Woodard]

Events cross the boundary.

The data in that event no longer "belongs" to the originating service. It has made that data "public" by the act of publishing the event.

The context that consumes the event can capture that data and do whatever it pleases with the data.

In that respect, the data is not "cached". It has been transformed and is now owned by the consuming context.

That also reveals the coupling inherent in Events which cross boundaries.

I hesitate to put forth an example.

What sort of data do you see Sales needing from the ProductCatalogue?

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

[sherifsa...@gmail.com]

Sales might require the weight of an item from the ProductCatalogue to do some calculate the shipping cost. I have once worked on an application that was trying to guess the weight of a book by collecting data from almost 50 different sources with predefined prioritization.

So at the moment I'm calculating the shipping cost I must ask the ProdutCatalogue for the last weight.

This is only an example though. I might have other bounded contexts that are asking for a book title or description.

[Thomas Presthus]

Have you considered moving product weight AND shipping cost esimation into a shipping context, thus removing the need to share this between contexts?

[sherifsa...@gmail.com]

I'm just using this an example to show when a bounded context needs data from another bounded context. Bounded contexts can't be 100% isolated from each other and will require data from its neighbors at some time.

[Kijana Woodard]

That's not true, depending on how you arrange things. [ex: http://www.infoq.com/presentations/SOA-Business-Autonomous-Components]

ProductCatalog could publish ProductMadeReadyForSale { productid }.

Sales sells "product ids". 

The screen that the user interacts with is a composite ui from Sales, ProductCatalog, Shipping, Billing, etc.

The cases where data is "needed" from other contexts are fewer than one might think. Typically in those cases, the data changes meaning when it crosses the boundary. 

It really comes down to your domain + applications and what makes sense there.

[Chris Sampson]

Ideally only id's should be used between contexts, if you are sharing data across contexts then maybe the boundaries aren't quite correct

[J Fernandes]

In my current project we're emitting events (ids only) between bounded
contexts and then letting the subscribers manage their own
requirements.

One case I did find is that we have business rules setup at the
Financial Product that need to be validated in order to generate a
Quotation. I'm not sure if this is just bad modelling on our side but
in this case we're allowing our Quotation BC subscriber to replicate
the rules setup at the Financial Product BC (this data is fetched by
the subscriber through an API call to the Financial Product BC).

Not sure if that helps... Let me know if you have any queries.

Best regards,

J Fernandes

[mynkow]

Exactly Sammo => Ideally only id's should be used between contexts, if you are sharing data across contexts then maybe the boundaries aren't quite correct

If you want to display or use data from different BCs you have several options:

1) Composite UI where every component loads its own data and display it (Amazon?, right?)

2) Build a gateway which responsibility is to query two or more BCs and combine the results

3) Build a projection database. You can subscribe to the internal events of other BCs and project the events to the database. Careful, do not mix published events which contain only ID with the internal events.

Basically all 3 approaches do exactly one thing in different ways. Combining data from two or more BCs for READ purposes only.

[sherifsa...@gmail.com]

OK let me use a more explicit example from an application I've seen before.

We are building a forum where Authors can create Posts while only Admins are allowed to delete Posts. The Identity BC manages Users and their Roles while the Post BC is responsible for managing the Posts, Replies,...etc.

When the Post BC receive a delete Post command I must check first if the user has the right role to do so, so the Post BC will ask the Identity BC if user with id=XXX has the role=admin or not.

Does that make sense?

[Kijana Woodard]

Security isn't part of the Posts responsibilities.

The command should be accepted/rejected upstream.

--

[Chris Sampson]

Yep that sounds like a claims thing cross cutting your commands and accepting or rejecting them according to current users claims

--

[Christer Unestrand]

Not necessarily. While I agree that authentication probably should be handled upstreams, authorization can very much be a BC-specific concern. Many times authorization is actually enforcing business rules local to a BC. Of course, if the authorization being performed is of the nature "should this user be able to access this BC at all", then the upstream Identity BC could take care of it.

Using the Post example to describe a general approach, I'd consider letting the upstream Identity BC perform the authentication, look up the user's associated claims (e.g. "userId=xxx", "role=admin") and augment the command message with those claims before letting the infrastructure pass the command along to the Post BC. The Post BC would then accept/reject the command according to it's business rules fed with those claims, possibly in conjunction with supplementary local data. With this division of concerns, we have a better chance of upholding SRP.

Granted, the distinction between authorization and business rules can be really blurry. It kinda depends, right? :)

BR,

Christer 

[oguzh4n]

Same example with:https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_collaboration/src/main/java/com/saasovation/collaboration/domain/model

İdentity bc is upstream of collaboration bc.
https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_identityaccess/src/main/java/com/saasovation/identityaccess

[oguzh4n]

And:https://seabites.wordpress.com/2014/07/20/trench-talk-authorization/