3

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.

theDmi
  • 17,546
  • 6
  • 71
  • 138
Normand Bedard
  • 2,625
  • 2
  • 19
  • 22

1 Answers1

2

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.

theDmi
  • 17,546
  • 6
  • 71
  • 138
  • In the case where the model is very simple, could you also consider exposing the access of the repositories directly to the other bounded context? Could this be useful to let the consumer bounded context manages and decides the way database transaction scope are configured instead of letting the supplier context manage it in a "general" way for all consumer context? – Normand Bedard Jun 14 '16 at 12:46
  • I'd try to avoid it, in the same way as I'd try to avoid exposing the domain model directly. You can of course take that approach, but be aware that this leads to very high coupling between the two BCs. Don't avoid the extra app services because they seem like a lot of code - they add an important layer of abstraction, and implementing & maintaining them is usually straight-forward. – theDmi Jun 14 '16 at 12:53
  • Do you agree that what you are describing looks like an OHS? I was thinking an OHS is a further step in the evolution of a bounded context, when multiple consumers always do the same ACL logic, and where your system is enough mature to expose a "real" public signature, allowing the ACL removing of all consumer. – Normand Bedard Jun 14 '16 at 13:40
  • No, an OHS (as I understand it) is an *open* (i.e. not consumer-specific) service. Your supplier app services will be designed along the requirements of the one specific consumer, so you really have a supplier-consumer relationship. Creating an OHS is usually much more effort, because you need to build a *service* that must make sense in a variety of applications. – theDmi Jun 14 '16 at 13:56
  • Open Host is just one of the patterns. All of them are described in the red book. If this is one "application" (although we know that application boundaries are a good match for bounded context boundaries), I would use something like MediatR. – Alexey Zimarev Jun 14 '16 at 16:33