Book Image

Domain-Driven Design with Java - A Practitioner's Guide

By : Premanand Chandrasekaran, Karthik Krishnan
Book Image

Domain-Driven Design with Java - A Practitioner's Guide

By: Premanand Chandrasekaran, Karthik Krishnan

Overview of this book

Domain-Driven Design (DDD) makes available a set of techniques and patterns that enable domain experts, architects, and developers to work together to decompose complex business problems into a set of well-factored, collaborating, and loosely coupled subsystems. This practical guide will help you as a developer and architect to put your knowledge to work in order to create elegant software designs that are enjoyable to work with and easy to reason about. You'll begin with an introduction to the concepts of domain-driven design and discover various ways to apply them in real-world scenarios. You'll also appreciate how DDD is extremely relevant when creating cloud native solutions that employ modern techniques such as event-driven microservices and fine-grained architectures. As you advance through the chapters, you'll get acquainted with core DDD’s strategic design concepts such as the ubiquitous language, context maps, bounded contexts, and tactical design elements like aggregates and domain models and events. You'll understand how to apply modern, lightweight modeling techniques such as business value canvas, Wardley mapping, domain storytelling, and event storming, while also learning how to test-drive the system to create solutions that exhibit high degrees of internal quality. By the end of this software design book, you'll be able to architect, design, and implement robust, resilient, and performant distributed software solutions.
Table of Contents (17 chapters)
Part 1: Foundations
Part 2: Real-World DDD
Part 3: Evolution Patterns

Continuing our design journey

In the preceding chapters, we had a solution for LC Application Processing that worked as an in-process component of the remainder of the overall application. From a logical perspective, our realization of the LC application is similar to the following diagram:

Figure 10.1 – The current view of the LC application monolith

Although the LC Application Processing component is loosely coupled with the rest of the application, we are still required to coordinate with several other teams to realize the business value. This could inhibit our ability to innovate at a pace that is faster than the slowest contributor in the ecosystem. This is because all teams need to be production-ready before a deployment can happen. This can be further exacerbated by the fact that individual teams might be at different levels of engineering maturity. Let’s look at some options regarding how we can achieve a level of independence from the...