A domain driven delivery

Microservices are fast becoming a mainstay of developing applications (except when Prime Video had to move back to monoliths due to too many serverless functions). Smaller teams that can work on things without blocks, the lessening of coupling programatically which makes it easier to build and test, they are independently deployable so we can make new things and experiment quickly and most importantly, they are flexible — can be coded in multiple languages where poeple of different expertises can all be of help. It comes with it’s own complexities, sure, but whenever a company thinks of scaling up they have to think about seperation of concerns and scaling is always better horizontally, not vertically. A growing codebase is something which is mutating all the time, growing parts, so to say and we don’t want it to grow into a monster.

In comes Domain Driven Development, or hereafter referred to as DDD for my fingers’ sake. The most important concern when making microservices from a monolith is the boundary where you split. Microservices make sure that there are no functional interdependencies. Service A will keep running even if Service B shuts down. This would happen even if Service A had API calls to Service B, so it’s important to focus on understanding and modeling the core business domains within an application.

We will be taking the example of a famous pizza chain, EazyBake Corp. and how it may be developing microservices using DDD to better serve their customers and of course, maximize profits!

Even before development begins we have to start thinking about bounded contexts, a bounded context is made by drawing a boundary where explicit and related responsibilities need to be carried out. A bit vague that explanation but let’s take the context of our EazyBake Corp., a pizza chain which has multiple branches around the world. Every branch recieves multiple orders every day and all these orders are assigned to appropriate personnel to be delivered. Everything that occurs in our corporation needs to be split up. Bounded contexts hide implementation details but what they do is expose contracts, a certain set of instructions that will happen when you call the domain’s service. For example, some bounded contexts that we can think of for our corporation are Orders, Inventory, Delivery and so on. A customer would place an order using the Orders’ exposed contracts, the Orders’ contract would then call Inventory and so on, in fulfilling one order, a saga(a topic for another post) would be created.

Another thing to keep in mind is when deciding domains there should be ubiquitous language between domain experts and the developers, meanings should be clear, for example in EazyBake Corp. terms like “order,” “pizza size,” and “delivery address” should have a clear and common meaning for both the development team and the pizza shop staff who are going to be taking orders and interacting with the interfaces daily.

Now what we need to do is represent loose collections of our domain’s concept as an object. An aggregate is a cluster of related entities and value objects treated as a single unit. For example, in our pizza chain, an order might be an aggregate that includes customer information, pizza selections, and delivery details. These items individually have no meaning except maybe to the customer as our domains are split, but put them together you begin to get an idea of what all is actually happening in the real world when an order is placed.

You must be thinking, there’s a lot that has been introduced and sure, it has helped you understand what DDD is, but why DDD? Well let’s get into the advantages:

Clear and Shared Understanding

By adopting a ubiquitous language, everyone involved in the project, from developers to business analysts and domain experts, shares a common understanding of EazyBake’s domain. This clarity helps in reducing miscommunication and ensures that the software accurately reflects the business requirements.

Improved Maintainability

Breaking down the system into bounded contexts and aggregates allows for easier maintenance and updates. Developers can work on specific parts of the application without affecting other areas, making it simpler to scale and evolve the system over time.

Flexibility and Adaptability

In a competitive market like pizza delivery , the ability to adapt to changing customer preferences and market trends is crucial. DDD’s focus on modeling the core domain means that changes can be made more quickly and efficiently, allowing the pizza delivery service to stay competitive.

Quality Assurance

With a clear understanding of the domain and well-defined models, it becomes easier to write comprehensive tests that cover the critical aspects of the application. This results in higher software quality and more robust applications.

Better Collaboration

DDD encourages collaboration between developers and domain experts throughout the development process. This collaborative approach ensures that the software aligns closely with the business needs and goals.

Enhanced User Experience

A well-modeled domain leads to a more intuitive and user-friendly application. Customers using EazyBake’s application will appreciate the ease of placing orders and tracking deliveries, ultimately leading to higher customer satisfaction.

May all these points lead you into splitting your next big business across domains so that you too can make it big, just like EazyBake!