Sometimes it’s best not to overdo the "DDD" when shaping the boundaries in your software architecture.
Using techniques like EventStorming you might achieve a clear conceptual model with well defined subdomains that domain experts agree with.
But it’s also important to analyse data flows: What information does a subdomain need from other subdomains to apply rules and make decisions?
Recently I hit this scenario...
1/2
For subdomain A (SA) to make a decision and produce event A1, it needed to consume ~10 event types from subdomain B (SB).
All the information to produce event type A1 was in the data provided by SB. So why introduce those dependencies and data synchronisations when the decision could be made directly in SB?
Conceptual models are a good starting point, but it's important to validate them with real use cases and detailed information flows.
2/2
Nick Tune