Return to Answer

You can solve this by creating two additional packages

   SalesEvents(OrderPlaced)

   BillingEvents(PaymentReceived)

instead of one Events package. It should be clear that the cyclic dependency vanishes here, since SalesEvents and BillingEvents don't reference each other, and Sales as well as Billing both reference SalesEvents and BillingEvents, but not each other.

Now let us compare this solution to the drawbacks you listed:

1. For example, Sales and SalesEvents belong to the same bounded context, so each corresponding Event stays in it's context.

2. There is not one "god" package any more which is going to "explode" by getting more and more events with each new microservice.

3. Additional services can exactly reference the events they require.

so this solves all the three issues.

This is also known as "Interface segregation principle", which can be applied not only to classes, but to packages as well.

You can solve this by creating two additional packages

   SalesEvents(OrderPlaced)

   BillingEvents(PaymentReceived)

instead of one Events package. It should be clear that the cyclic dependency vanishes here, since SalesEvents and BillingEvents don't reference each other, and Sales as well as Billing both reference SalesEvents and BillingEvents, but not each other.

Now let us compare this solution to the drawbacks you listed:

1. For example, Sales and SalesEvents belong to the same bounded context, so each corresponding Event stays in its context.

2. There is not one "god" package any more which is going to "explode" by getting more and more events with each new microservice.

3. Additional services can exactly reference the events they require.

so this solves all the three issues.

This is also known as "Interface segregation principle", which can be applied not only to classes, but to packages as well.

You can solve this by creating two additional packages

   SalesEvents(OrderPlaced)

   BillingEvents(PaymentReceived)

instead of one Events package. It should be clear that the cyclic dependency vanishes here, since SalesEvents and BillingEvents don't reference each other, and Sales as well as Billing both reference SalesEvents and BillingEvents, but not each other.

Now let us compare this solution to the drawbacks you listed:

1. For example, Sales and SalesEvents belong to the same bounded context, so each corresponding Event stays in it's context.

2. There is not one "god" package any more which is going to "explode" by getting more and more events with each new microservice.

3. Additional services can exactly reference the events they require.

so this solves all the three issues.

You can solve this by creating two additional packages

   SalesEvents(OrderPlaced)

   BillingEvents(PaymentReceived)

instead of one Events package. It should be clear that the cyclic dependency vanishes here, since SalesEvents and BillingEvents don't reference each other, and Sales as well as Billing both reference SalesEvents and BillingEvents, but not each other.

Now let us compare this solution to the drawbacks you listed:

1. For example, Sales and SalesEvents belong to the same bounded context, so each corresponding Event stays in it's context.

2. There is not one "god" package any more which is going to "explode" by getting more and more events with each new microservice.

3. Additional services can exactly reference the events they require.

so this solves all the three issues.

This is also known as "Interface segregation principle", which can be applied not only to classes, but to packages as well.

You can solve this by creating two additional packages

   SalesEvents(OrderPlaced)

   BillingEvents(PaymentReceived)

instead of one Events package. It should be clear that the cyclic dependency vanishes here, since SalesEvents and BillingEvents don't reference each other, and Sales as well as Billing both reference SalesEvents and BillingEvents, but not each other.

Now, if you see Sales and SalesEvents both belonging to the same bounded context, it is clear which event belongs to which context. Moreover, there is not one package which is going to "explode" by getting more and more events with each new microservice, and additional services can exactly reference the events they require.

You can solve this by creating two additional packages

   SalesEvents(OrderPlaced)

   BillingEvents(PaymentReceived)

instead of one Events package. It should be clear that the cyclic dependency vanishes here, since SalesEvents and BillingEvents don't reference each other, and Sales as well as Billing both reference SalesEvents and BillingEvents, but not each other.

Now let us compare this solution to the drawbacks you listed:

1. For example, Sales and SalesEvents belong to the same bounded context, so each corresponding Event stays in it's context.

2. There is not one "god" package any more which is going to "explode" by getting more and more events with each new microservice.

3. Additional services can exactly reference the events they require.

so this solves all the three issues.