Book Image

Microservices with Clojure

By : Anuj Kumar
Book Image

Microservices with Clojure

By: Anuj Kumar

Overview of this book

The microservice architecture is sweeping the world as the de facto pattern with which to design and build scalable, easy-tomaintain web applications. This book will teach you common patterns and practices, and will show you how to apply these using the Clojure programming language. This book will teach you the fundamental concepts of architectural design and RESTful communication, and show you patterns that provide manageable code that is supportable in development and at scale in production. We will provide you with examples of how to put these concepts and patterns into practice with Clojure. This book will explain and illustrate, with practical examples, how teams of all sizes can start solving problems with microservices. You will learn the importance of writing code that is asynchronous and non-blocking and how Pedestal helps us do this. Later, the book explains how to build Reactive microservices in Clojure that adhere to the principles underlying the Reactive Manifesto. We finish off by showing you various ways to monitor, test, and secure your microservices. By the end, you will be fully capable of setting up, modifying, and deploying a microservice with Clojure and Pedestal.
Table of Contents (18 chapters)
Title Page
Dedication
Packt Upsell
Contributors
Preface
Index

Domain-driven design


Ideal enterprise systems are tightly integrated and provide all business capabilities as a single unit that is optimized for a particular technology stack and hardware. Such monolithic systems often grow so complex over time that it becomes challenging to comprehend them as a single unit by a single team. Domain-driven design advocates disintegrating such systems into smaller modular components and assigning them to teams that focus on a single business capability in a bounded context (https://en.wikipedia.org/wiki/Domain-driven_design#Bounded_context). Once disintegrated, all such components are made a part of an automated continuous integration (CI) process to avoid any fragmentation. Since these components are built in isolation and often have their own data models and schema, there should be a well-defined contract to interact with the components to coordinate various business activities.

Note

The term Domain-driven design was first coined by Eric J. Evans as the title...