How to integrate bounded context when creating aggregates and entities?

2
votes

I am trying to appy DDD principles along with CQRS, and I am having trouble integrating bounded contexts.

Let us consider the Catalog and Billing contexts in a marketplace domain. I modeled the Product concept as an Entity of the Catalog Aggregate in the 1st BC, and as an Aggregate in the latter.

Now I have this "merchant UI" where a merchant can add Products to his Catalog. when doing this, he'll provide the Product's name, description and some other classification & customization data, as well as it's selling price, discount policy etc ...

How should I communicate the creation of a Product in both Bounded Contexts ? I have considered the following approaches, but none of them feels right to me:

  • create a single command gathering all of the data the merchant has provided through the UI, and then have a controller or an application service integrate both Bounded Contexts and dispatch specialized commands to each one

  • add the pricing information to the Catalog BC and trigger an event (or use a database trigger) to inform the Billing BC of the Product creation

What would be a satisfying alternative approach ?

Thanks

1
domain-driven-designcqrs

1 Answers

1
votes

How about this?

In the Catalog context, the Product is modeled as an Entity, which seems right to me.

In the Billing context, the Product could be a Value Object, translated from the Catalog context via an anti-corruption layer. Only the details needed for billing purposes should be included in this model of the Product.

If using CQRS in the Billing context, you may find you need to refresh the query model. That is, to create a new Product Value Object. To do this, I agree than an event notification would be needed. Upon receiving a message to refresh its query model, the Billing context would access an Application Service in the Catalog context, which may have its own CQRS architecture or something else.

I'm not sure why the Product would need to be an Aggregate in the Billing context. Does the Product need to have command methods in the Billing context, or does it have its own repository?

My guess is you'd thank yourself to avoid combining contexts within an Application Service, though it could be best idea for some situations. In general, though, an Application Service belongs to a single Bounded context.