Skip to content

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.


Follow @CodeOpinion

Derek Comartin

Handling Failures in Message Driven Architecture

Many great libraries help to add resilience and fault tolerance by handling failures in a message driven architecture. However, it’s not just as simple as adding retries, timeouts, circuit breakers, etc., globally to all network calls. Many implications are specific to the context of the request being processed. And in many cases, it’s not solely a technical concern but rather it’s a business concern. YouTube Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that is in this post. Handling Failures Transient Faults are happening randomly. They are failures that… Read More »Handling Failures in Message Driven Architecture

Real-Time Web by leveraging Event Driven Architecture

Event Driven Architecture isn’t just for communicating between services or systems. It’s a characteristic of your architecture. You can develop a monolith and still use event driven architecture. Here’s an example of how using events can drive real-time web and make your clients more interactive. YouTube Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that is in this post. Simple Event Processing The basics of Event Driven Architecture are Events, Producers, and Consumers. To start with a Producer will create an Event. An event is simply a message that… Read More »Real-Time Web by leveraging Event Driven Architecture

STOP doing dogmatic Domain Driven Design

The mainstream thought on Domain Driven Design is about Entities, Value Objects, Aggregates, Repositories, Services, Factories… all kinds of technical patterns. Because of this, most don’t think they need Domain Driven Design because it’s complicated for their domain. Why would you need all that “stuff”? Well, maybe you don’t! In a large system, modeling your domain, defining boundaries, and how they relate is far more important than concerning yourself if you’re using the Repository pattern correctly. YouTube Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that is in this… Read More »STOP doing dogmatic Domain Driven Design