domain driven design
-
CloudEvents as a Data Product
TL;DR Treat CloudEvents as the envelope for versioned, traceable domain aggregate snapshots. Use the CloudEvents contract for transport and a versioned aggregate schema in data to make events reliable event-based data products for analytics, ML, and agentic workloads. This post expands on the Event as a Data Product pattern I introduced in my previous article. At its core: treat domain aggregates (your key Continue reading
-
KAPPA your Domain Model into the Data-Mesh Architecture as Events
Use ‘Events as a Data Product’ in the Data-Mesh by applying ‘Data on the outside’ thinking using KAPPA architecture: Continue reading
-
Events on the Outside vs Events on the Inside
Apply learnings of Pet Helland’s paper “Data on the Outside versus Data on the Inside” on Event Driven Systems Continue reading
-
Events Love Commands
Furthermore to my previous post where I tried to compare events and commands, here I am presenting a scenario where they complement each other. As discussed, both of them are types of the messages and used for different purposes; while event messages are a backbone of the event-driven system, I believe that commands can add Continue reading
-
Decouple Entity Framework based monolith to well defined bounded contexts.
Domain Driven Design (DDD) is the widely accepted and proven pattern to build applications dealing with complex domains. Not many applications manage to maintain the clear boundaries between bounded contexts as they grow bigger. Even if it is realised, the high costs of refactoring discourage to bring things back on track. The cost of refactoring gets Continue reading
code simple { } 