DDD Bounded Context integration - Application Service vs Domain Service vs Repositories

Question

I have a bounded context with an Application Service exposing application use cases with DTOs.

The bounded context also includes a Domain Service exposing domain use cases with rich domain objects. Application Service is the "client" of the Domain Service.

And finally, repositories allowing the persistence of the domain objects.

Other bounded context exist in the domain, and the relationship between teams owning the bounded context is customer/supplier, so teams align to the same goal and can cooperate to expose required use case to the other bounded context.

In this situation, where the "customer bounded context" should connect to the "supplier bounded context"?

Is is okay for the "supplier bounded context" to directly access the repositories or the domain service exposing rich domain objects of the "supplier bounded context"? (With an ACL in the "customer bounded context" that shields the "supplier bounded context" from leaking in the domain). I am not sure this approach is good because domain refactor will break all the ACL and require maintenance. I know this is the goal of an ACL but...

Or is it preferable for the "consumer bounded context" to connect only to the application service of the "supplier bounded context", where public DTO are exposed? (without the need of an ACL). I am not sure this approach is good because it forces the Application Service to mimic the Domain Service only to serve as an access point, even if the use case is clearly a Domain use case.

Any opinions? Anyone has tried one of the two approches with good/bad experiences?

I do not find clear answers from Vaughn Vernon book or Scott Millett book.

Answer 1

The two teams should collaborate to define an API for the supplier BC. Don't just directly couple to other BC app services or even the model.

The API is often realized as a REST API, but from your question it sounds like you're integrating multiple BCs in one application. If that's the case, then you should define the API as a interface library.

The interface library should be versioned and documented. It should be maintained by the supplier team, with the consumer team making change requests according to their needs.

Only expose the domain model itself through the API if the supplier BC has a VERY simple model. In all other cases, it makes sense to define app services that encapsulate the required use cases. Then, only these app services would be exposed as API.