Once upon a time I was use to listen a business requirement and automatically visualize its relational schema mapping nouns to entities/tables. I was proud of myself quickly defining a model with little logic, a service layer, business logic, an ORM library to manage et voila… something working showing it to the business stakeholders. Let… Continue reading Horrible Architectures: 3 layers camouflage
…in the beginning I was interested in what is the structure of software. People in hardware have it all easier. When you build machines, you have obvious components connected by wires and this forces you to a kind of natural modularity. Each component does whatever its doing and provides a simple way interacting with the… Continue reading Structure of software in a distributed architecture
In our journey we started with a business requirement, we model the requirement with commands, events, we ingest input data, we process the data, we implemented processing components using Event Sourcing pattern and we stored our Domain Events in small streams. All this represent the way to define and feed our write model. The benefit… Continue reading Distributed Architecture 03: CQRS and Data Distribution
“Commands have an intent of asking the system to perform an operation where as events are a recording of the action that occurred…” Greg Young, CQRS Documents Pag. 26 In this post I’d like to state something that I’ve just recalled from a Greg Young’s video. When I started creating an aggregate root I often… Continue reading Domain Driven Design: Commands and Events Handlers different responsibilities
