book

Event-Driven Architecture in Golang

by Michael Stack

November 2022

Intermediate to advanced

384 pages

8h 47m

English

Packt Publishing

Read now

Unlock full access

ContributorsAbout the authorAbout the reviewers
Who this book is forWhat this book coversTo get the most out of this bookDownload the example code filesDownload the color imagesConventions usedGet in touchShare Your ThoughtsDownload a free PDF copy of this book
Technical requirementsAn exchange of factsEvent notificationsEvent-carried state transferEvent sourcingCore componentsWrap-upThe MallBots applicationThe pitchApplication servicesAPI gateway servicesClientsA quick note about hexagonsBenefits of EDAResiliencyAgilityUser experience (UX)Analytics and auditingChallenges of EDAEventual consistencyDual writesDistributed and asynchronous workflowsDebuggabilityGetting it rightSummary
Domain-driven designDDD misconceptionsSo, what is it all about then?How is it useful for EDA?Domain-centric architecturesAn evolving solutionHexagonal architecture appliedTestingA rulebook, not a guidebookShould you use domain-centric architectures?How is it useful for EDA?Command and Query Responsibility SegregationThe problem being solvedApplying CQRSWhen to consider CQRSCQRS and event sourcingTask-based UIApplication architecturesMonolithic architectureMicroservicesRecommendation for green field projectsSummaryFurther reading
Technical requirementsWhat are we building?Finding answers with EventStormingWhat is EventStorming?Big Picture EventStormingDesign-level EventStormingUnderstanding the businessRecording architectural decisionsSummaryFurther reading
Technical requirementsA tour of MallBotsThe responsibilities of the monolithModule code organizationUser interfaceRunning the monolithA focus on event-driven integration and communication patternsTaking a closer look at module integrationUsing external dataCommanding external componentsTypes of eventsDomain eventsEvent sourcing eventsIntegration eventsRefactoring side effects with domain eventsWhat about the modules not using DDD?Summary
Technical requirementsWhat is event sourcing?Understanding the difference between event streaming and event sourcingAdding event sourcing to the monolithBeyond basic eventsAdding the event sourcing packageUsing just enough CQRSA group of stores is called a mallA group of products is called a catalogTaking note of the little thingsConnecting the domain events with the read modelRecapping the CQRS changesAggregate event stream lifetimesTaking periodic snapshots of the event streamUsing snapshotsSummary
Technical requirementsAsynchronous integration with messagesIntegration with notification eventsIntegration with event-carried state transferEventual consistencyMessage-delivery guaranteesIdempotent message deliveryOrdered message deliveryImplementing messaging with NATS JetStreamThe am packageThe jetstream packageMaking the Store Management module asynchronousModifying the monolith configurationUpdating the monolith applicationProviding to the modules the JetStreamContextPublishing messages from the Store Management moduleReceiving messages in the Shopping Baskets moduleVerifying we have good communicationSummary

Technical requirementsRefactoring to asynchronous communicationStore Management state transferCustomer state transferOrder processing state transferPayments state transferDocumenting the asynchronous APIAdding a new order search moduleBuilding read models from multiple sourcesCreating a read model recordSummary
Technical requirementsWhat is a distributed transaction?Why do we need distributed transactions?Comparing various methods of distributed transactionsThe 2PCThe SagaImplementing distributed transactions with SagasAdding support for the Command and Reply messagesAdding an SEC packageConverting the order creation process to use a SagaAdding commands to the saga participantsImplementing the create order saga execution coordinatorSummary
Technical requirementsIdentifying problems faced by distributed applicationsIdentifying problems in synchronous applicationsIdentifying problems in asynchronous applicationsExamining potential ways to address the problemThe singular write solutionExploring transactional boundariesHow the implementation will workThe di packageUpdating the Depot module with dependency containersUsing an Inbox and Outbox for messagesImplementing a messages inboxImplementing a messages outboxSummary
Technical requirementsComing up with a testing strategyUnit testsIntegration testsContract testsEnd-to-end testsTesting the application and domain with unit testsTable-driven testingCreating and using test doubles in our testsTesting dependencies with integration testingIncorporating the dependencies into your testsRunning tests with more complex setupsTesting ProductCacheRepositoryBreaking tests into groupsTesting component interactions with contract testsConsumer expectationsProvider verificationsNot building any silosContract testing with PactREST consumer and provider exampleMessage consumer and provider exampleTesting the application with end-to-end testsRelationship with behavior-driven developmentE2E test organizationMaking executable specifications out of our featuresWhat to test or not testSummary
Technical requirementsTurning the modular monolith into microservicesRefactoring the monolith constructUpdating the composition root of each moduleMaking each module run as a serviceUpdates to the Dockerfile build processesUpdates to the Docker Compose fileAdding a reverse proxy to the compose environmentFixing the gRPC connectionsInstalling the necessary DevOps toolsInstalling every tool into a Docker containerInstalling the tools into your local systemUsing Terraform to configure an AWS environmentPreparing for the deploymentA look at the AWS resources we are deployingDeploying the infrastructureViewing the Kubernetes environmentDeploying the application to AWS with TerraformGetting to know the application resources to be deployedDeploying the applicationTearing down the application and infrastructureSummary
Technical requirementsWhat are monitoring and observability?The three pillars of observabilityHow tracing worksInstrumenting the application with OpenTelemetry and PrometheusAdding distributed tracing to the applicationAdding metrics to the applicationViewing the monitoring dataSummary
Other Books You May EnjoyPackt is searching for authors like youShare Your ThoughtsDownload a free PDF copy of this book

Content preview from Event-Driven Architecture in Golang

Preface

Companies are adopting event-driven architecture (EDA) as their web applications grow in size and complexity. Applications that communicate using events are easier to develop and scale. Adding or developing your application around real-time interactions becomes easier with EDA.

Direct point-to-point communication between microservices inevitably leads to the development of a distributed monolith, which is just a monolith with extra and unnecessary complexity. EDA is an architecture that helps organizations to decouple microservices and avoid developing another distributed monolith.

Choosing a new architecture for your next application or deciding to refactor an existing one can be fraught with known and unknown challenges. It is my intention ...