Read the model for limited context

Question

I have a question related to reading models in cqrs.

Suppose we have two limited contexts: A and B

In context A, we create event-based readmodel from context A. We have some kind of dao to access readmodel in A.

Suppose B requires the same reading model as A. As I understand it, a limited context should not depend on each other.

So, how can I use the model from A. I see three possibilities to solve this problem.

• Create an API module for the model you read in and use this in context B (There will be a dependency between A and B)

• Create a separate reading model in context B, which is exactly the same as in A (Will lead to code duplication)

• Create a facade of the service (REST or SOAP or something else) in B accessible from A to provide a readable model (perhaps the service does not provide exactly the necessary data)

Answer 1

Your read models do not belong to any limited contexts, they are created for some domain objects in some limited context. But they are a separate component of your system.

In your limited context, no model you read is required . The reading model is the output of the domain, not the input. If you need 2 BC communication, use events rather than read models. Read models for GUI / reporting, not for processing business rules.

Answer 2

In fact, dependencies between contexts are very common, see relations and context matching in the DDD Reference .

In your example, context B depends on context A. Depending on the type of relationship (up-down-down, partnership, ...), context A decides how to include context B with them (open-host, customer / supplier, ... )

Context A can provide a reading model, an event, or both. Integration through events gives you independence, although integration using a reading model may be more practical for your example (but it can cause friction when context A decides to diverge). Factors to consider are your relationships with a different context, as well as the likelihood of a change or the cost of the change.