Week 22, year 2019
- DDD Weekly: Issue #60 - Patterns for Decoupling in Distributed Systems [twitter/blog] Mathias Verraes. Consumer-driven Coupling: Patterns and Anti-patterns [blog] Nick Tune. Designing microservices can feel quite easy at times. And that’s because it is at first. However we slice our system and our teams, it usually works to begin with. The cost of poor design doesn’t begin to manifest until the system starts to scale. The feedback loop on sociotechnical design choices is long. [DDD Weekly]
- Messaging Patterns: Natural Language Message Names - Problem Our industry has a tradition of unnatural, compact, lossy naming. This may save on typing, but costs in understandability. Solution Naming is hard, because we name things. If we understand the domain and have discussed with domain experts, we don’t have to invent names, we can use the names from that domain. And no domain experts says Payment Event or Invoice Paid or OnAfterPayment, they say The invoice was paid. Use descriptive, natural language names. [Mathias Verraes]
- Eventsourcing Patterns: Migration Events in a Ghost Context - Explicitly conform to the legacy component’s model in an eventsourcing migration. Problem We are replacing a Legacy component with a new Eventsourced component. Besides being fully Eventsourced, the new component has a clear domain model with a well-defined Ubiquitous Language. The domain events are granular, and named in this language, and track the entire history of the component. The new component needs to retain and use data produced by the old component. The old component stores state, but no history. [Mathias Verraes]
- Eventsourcing Patterns: Decision Tracking - Decision Tracking Store the outcome of a decision to guard against rule changes. Problem In an eventsourced system, a consumer listens to a stream of events. IT has some business logic that makes decisions, and acts upon those, for example in the form of a side effect or a new event. Because we’ve already stored the input events in the event store, we can recalculate that decision. Should our event store persist an event that represents that decision? Solution Often, the reasoning is that the event that represents the decision, is redundant. We could store it, but we can recalculate it, so we don’t have to store it. [Mathias Verraes]