124: Understanding the business needs

Learning about business needs, constraint through collaborative knowledge crushing

Welcome to Snippets of Text! Today's snippets delve into the importance of understanding business requirements beyond technical aspects and utilizing impact mapping for knowledge exploration. I value your insights and encourage you to share your thoughts in the comments section. Thank you for being a part of our community.

Unrelated: Decoupled Communication in Applications

Bounded contexts are data and code. Bounded context and you have another bounded context, and bounded context consists of data and code that encodes.

Bounded contexts communicate using events to decouple the communication. They can consume this, and whatever they need, they can store it in their data, duplicating it but not. Usually, the other context only requires parts of their data, only some things. It needs to be more engaging in everything. 

Events are the interface used for communication in an application. When you start publishing the domain events, the interface is moved here. The events have some attributes, and he uses the interface to communicate with the rest of your applications.

Events create a trackable sequence of facts that end up in the current state. If you look into the data, you might wonder why is it the data this way and not the other what happened? The prevention on the consumer side comes from the inversion of control. Data is private, and the publisher to publish my demands is their interface. They're public. That's where you need to care about compatibility with the consumers.

Event-first thinking changes how you think about what you are building. Capture facts. Capture behavior. Provide a representation of the real world. Model use cases of how. Supports repeated evaluation and processing (a time machine). Provide horizontal scaling. Speak the same language as the business. The approach is unique in that it processes the event as a reaction. The emitter doesn't call on a specific function; the API has been removed and instead sends an event. Don't do anything else, have no API coupling to a remote service.

The emitter of the event doesn't know which processors (or functions) will consume it, and the event becomes the API. This decoupling allows the consuming apps to change over time without any upstream changes required in the emitter. The power of the event-first process becomes clear when we try to enhance the system. 

[^1]: Implementing Domain-Driven Design