Jacek Milewski

How We Waste Time Building APIs — and the Moment DDD Starts to Matter

It started with a simple endpoint: /trainings. But this small choice led to leaked logic and a brittle system. Discover the moment DDD should have been applied.

How We Waste Time Building APIs — and the Moment DDD Starts to Matter
#1about 2 minutes

Designing an initial API for training coordination

A simple system for scheduling trainings evolves, leading to API endpoints for confirming trainings and booking resources.

#2about 2 minutes

The mistake of cloning services for new use cases

When a new requirement for scheduling meetups arises, the team duplicates the training planner service, creating technical debt.

#3about 1 minute

Introducing complex business logic like cancellation fees

A new business rule for room cancellation fees reveals a deeper architectural problem about where financial logic should reside.

#4about 3 minutes

Exploring flawed solutions and misplaced responsibility

Proposed solutions, like one service calling another's API for data, demonstrate the anti-pattern of crossing service boundaries for decision-making.

#5about 3 minutes

Recognizing hidden strategic decisions in API design

Different team perspectives show that seemingly small technical choices, like reusing an endpoint, are actually critical strategic business decisions.

#6about 2 minutes

Three key questions to guide architectural decisions

To avoid flawed designs, ask which bounded context owns a decision, who bears the long-term cost, and if the API increases team autonomy.

#7about 3 minutes

Applying large-scale structures to separate concerns

The system is reframed using capability layers (like resource booking) and operations layers (like training planning) to prevent domain logic from leaking.

#8about 6 minutes

Defining bounded contexts with an AI assistant

An AI twin helps formally define the purpose, language, and communication patterns for the Training Planner and Resource Booking bounded contexts.

#9about 4 minutes

Using simulations to future-proof your architecture

By imagining future use cases like booking desks or concert tickets, you can test the architecture's stability and avoid coupling to current requirements.

#10about 3 minutes

A framework for prioritizing potential features

A 2x2 matrix helps decide whether to implement, design for, or ignore potential features based on their likelihood and future implementation cost.

#11about 3 minutes

Making small, incremental architectural decisions

Instead of making large, slow decisions, focus on stabilizing small parts of the architecture to unblock teams and maintain momentum.

#12about 5 minutes

Correcting context maps and team topologies

The relationship between services is changed to an open host service model, supported by a team structure of platform and stream-aligned teams.

#13about 2 minutes

Uncovering the hidden 'Event Economics' bounded context

The cancellation fee problem is solved by identifying a new bounded context, 'Event Economics', which correctly owns the financial decision-making logic.

#14about 1 minute

The skill of applying DDD just in time

Effective architecture isn't about applying the entire DDD framework, but about using the minimal required concept at the precise moment it's needed.

Related jobs
Jobs that call for the skills explored in this talk.

Featured Partners

Related Articles

View all articles

From learning to earning

Jobs that call for the skills explored in this talk.