Member-only story
Redux and Doman-Driven Design
A short practical comparison
Dan Abramov, the creator of Redux, says that he does not know what Domain-Driven Design is. Still, it is impressive how Redux resembles DDD. In this article, I explain what DDD is, some key concepts, and how Redux implements its ideas. And understanding both, we can deliver even better implementations; two approaches from different worlds that collide and take advantage of the same design principles.
Domain-Driven Design
Domain-Driven Design is a software modeling technique designed to create robust microservices architectures as well as integrate multiple existing solutions.
Eric Evans initially presented it in 2003 in the book «Domain-Driven Design: Tackling Complexity in the Heart of Software.» Currently, DDD has many more books, more examples, and it has proved to be effective scaling and maintaining high-grade performance in large systems. If you have listened about Event-Sourcing or CQRS, then you have crossed your paths with DDD.
We can split DDD into two areas: strategy and tactics. The strategy introduces the Ubiquitous Language and Bounded Context. It creates a common language between the developers and the business, but this language goes beyond meetings: all documentation, stories, and even code shares that language…