I am part of a team responsible for a business-critical service that captures Submissions from end users. A submission navigates through a series of approval workflows, ultimately generating side effects across various downstream services.
These downstream services are independently managed and deployed by separate teams, each overseeing their own distinct applications
Challenge
The service played a role of a gatekeeper for data entering the system. Upon approval, the Submission triggered multiple CRUD operations across downstream systems. In our domain, the Submission in our domain was supposed to be IMMUTABLE.
Business requirements, like they do, changed. Business needed overrides to the Submission before approval, Like a person with appropriate rights could change something in the submission.
We needed the end users to understand what came in, what alternations were made and by whom and how the result was derived from this altered almost immutable request.
engineering bits
ledger of changes
We pressed on keeping Submission immutable as it represented what the original request was being made for.
Alternations to the Submission were recorded as an Event. The current state of the Submission was then derived by applying EditXXX event on the Submission
We setup our system where the domain events were captured as part of an audit trail using MartenDB
Implementation bits
The project uses Mediatr for handling CQRS requests and commands with entity framework at the persistence layer. Instead of applying changes to the Submission model, the CQRS handler would hydrate the domaine entity which would raise appropriate events
We setup an event listener which used MartenDB and stored the events under Submission.Id as the stream context. The projection SubmissionProjection was defined which Applied the events stored for the Submission to give users the current state of the Submission
Projection = Entity + Events
MartenDB allows you to define a live version of the Projection, which helps you avoiding loading all the events applied on an entity to get to the current state of the entity.
learnings
- transparency helped end users identify and at times correct configuration changes before they were applied
- the changes helped reduce support tickets and retroactive reversals, which at times could only be performed by technical support tier or worst case developers