I’ve noticed that bounded contexts made a lot more sense when all the communication between contexts happens using strictly Serializable Structs for both input and output (something like DTO). I think most people would benefit from using it and with just a few changes it could make your context easier to be self-contained and distributed in the future. Some gains of Serializable Structs interface:

1. Intuitively Forces the user to think about relationships between contexts like Shared Kernel (both contexts should agree on the format of the data), customer/supplier (the customer sets what he need to receive) and conformist (we just accept the data they send and adapt it; for example abstracting an external Api).

2. Have a clear contract with everything you need as input without unnecessary coupling. Pattern matching an external Structs used in business logic is weak since it should change fast and evolve independently of your domain but their public schemas should be stable and concerned about changes.

3. The output data could be serialized so it could easily substitute the default View. No extra complexity we are just moving it from to Web View layer to the Context View (I guess we could call Serializable Struct as Views?). The Web View layer could be skipped if no custom presentation are required.

4. When a struct used in business logic changes we have no clue that it will affect the external world since the context don’t know about controllers, views and other contexts. When we maintain a SerializableStruct inside of our context then it will be clear that it needs to be updated once a breaking change are required and it will also be clear that any change in the layout of this module WILL affect the outside world. You should never rely on a higher layer test to know if your local change will break something or not.

5. When used as input it will hint people about providing an Input Gate to validate and sanitize that external and untrusted data. We could hint people that once we convert those structs to domain structs we should treat the input data as safe and consistent. That way we have a clear separation between validating the input data and business logic.

6. You remove coupling in the communication and gains autonomy. It makes it easier to move from a monolith to other architectures… you just need to change how the messages flow.