Book Image

Event-Driven Architecture in Golang

By : Michael Stack
5 (1)
Book Image

Event-Driven Architecture in Golang

5 (1)
By: Michael Stack

Overview of this book

Event-driven architecture in Golang is an approach used to develop applications that shares state changes asynchronously, internally, and externally using messages. EDA applications are better suited at handling situations that need to scale up quickly and the chances of individual component failures are less likely to bring your system crashing down. This is why EDA is a great thing to learn and this book is designed to get you started with the help of step-by-step explanations of essential concepts, practical examples, and more. You’ll begin building event-driven microservices, including patterns to handle data consistency and resiliency. Not only will you learn the patterns behind event-driven microservices but also how to communicate using asynchronous messaging with event streams. You’ll then build an application made of several microservices that communicates using both choreographed and orchestrated messaging. By the end of this book, you’ll be able to build and deploy your own event-driven microservices using asynchronous communication.
Table of Contents (18 chapters)
1
Part 1: Event-Driven Fundamentals
5
Part 2: Components of Event-Driven Architecture
12
Part 3: Production Ready

A tour of MallBots

Our MallBots application is a modular monolith, which, if you recall from Chapter 2, Supporting Patterns in Brief, is an application design that sits somewhere between a classic monolith design and a microservices application design. We have most of the benefits of both designs with only a few downsides.

The responsibilities of the monolith

The root directory of our code is kept minimal and what stands out is the module names. We intentionally avoid the use of generic or general layer names, such as controllers, config, or models, in the root directory. We use application component names, such as baskets, stores, depot, and ordering instead, so that we end up with a code repository that looks like an application that deals with shopping and not like some generic, no-idea-what-it-does application. Each of these modules is a different bounded context in our application.

Screaming architecture

The organization we’re using for our root level directory...