I write about what I learn by building.

Having use cases, entities and repositories does not guarantee Clean Architecture. Using a fleet management system as an example, the article shows how anemic entities turn code into disguised transaction scripts and walks through the migration to a domain model: a self-validating Chassi value object, protected attributes, a factory method with default values and use cases that only orchestrate the rules.

Modularity goes beyond splitting code into technical layers. The article explains cohesion and coupling, shows why layered architecture creates lots of communication between modules and almost none within them, and argues for modularizing by business domain, inspired by DDD. The result is cohesive, decoupled modules that are ready to become independent services as the domain matures.

Microservices are not resilient by nature. Starting from the eight fallacies of distributed computing, the article shows that swapping in-memory calls for network calls creates new points of failure, and that resilience depends on what each service needs to guarantee. A system is never resilient to everything — only resilient to something.

Branches and commits without a standard turn history into noise. The article lists the problems caused by vague names and confusing messages and shows how branch naming conventions and semantic commits, in the prefix(module): description format, make the repository document itself.