How to handle changes to local and global representation of an Entity in a distributed environment?

Question

I'm a developer for a retail enterprise IT department, and am currently stuck on the following scenario:

Department A is responsible for a CRUD service that's used for handling stores - so when our company wants to open a new physical location, it goes through there.

I'm in department B, which amongst other things is responsible for a geo information system. We are of course interested in e.g. location data of stores. But to us, a store is one of several entities which are basically a point on a map, though each kind of point also has its own special attributes. So I'd like to integrate this store data into a more generalized data model (E.g. there is an abstract parent point table with coordinates and point-type, and then the point-specific attributes would be held in child tables).

So I was thinking about the following: Dept. A publishes changes to stores to a message queue, we consume that event and integrate this store data to our data model. If our users want to make changes to store attributes through our map application (for example move it, since this is still the planning phase), we'd call the service of dept. A.

What I'm stuck on in my thinking: What if my users want to extend the store data with certain attributes that are of no interest to Dept. A? So if I want to change the "base-data" through our front-end I'd have to call Service A, but if there's changes to these "local" attributes, it'd have to go through service B that we'd have to provide?

I'm thinking there might be DDD concepts that help with this, but I'm not sure how to word this scenario to get the right results.

Answer 1

Department A and B seem to be two distinct bounded context: B sees the Store with a slightly view from department A. And perhaps there's also departments C and D with still other views.

The way you are relating your bounded context is context mapping. There are some known strategies that can be used. For example:

• If it appears that your geographic attributes are of common interest, both departments could agree on managing a "shared kernel", a common subset of the model that is managed by both teams in coordination.

• If however the the geographic view is not of general interest:

  • You could be just conform to the department's A model for the Store, extend it with your additional attributes and publish those to other interested consuming services.
  • or if there's a risk that it might in the end not be so close in some rare cases (e.g. a store at a cross road with two addresses and an underground delivery place that is reachable for trucks via a third address), you may think of having an "anticorruption layer" in your design: the stores of department A are isolated in that layer from your view of the store, so that both can evolve independently with lower risk of change propagation. You may expose your own view to the other interested services, but it would be more difficult for them to relate in a sustainable way your aggregates with A's aggregates.