> Markdown version of [/videos/2064-how-we-waste-time-building-apis-and-the-moment-ddd-starts-to-matter?t=1449](https://www.wearedevelopers.com/videos/2064-how-we-waste-time-building-apis-and-the-moment-ddd-starts-to-matter?t=1449). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

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

Are innocent feature requests silently destroying your team's autonomy? Discover how applying Domain-Driven Design at the exact right moment rescues leaking API architectures.

- **Speakers:** [Jacek Milewski](https://www.wearedevelopers.com/@jacek-milewski)
- **Event:** World Congress 2026 Europe - Virtual Stage
- **Published:** July 2, 2026
- **Duration:** 41:36
- **URL:** https://www.wearedevelopers.com/videos/2064-how-we-waste-time-building-apis-and-the-moment-ddd-starts-to-matter

## Summary

Teams rarely fail due to a lack of technical practices; they struggle because they make strategic architectural decisions without realizing it, often hiding them behind API path segments or JSON parameters. Through the lens of a growing training coordination system, this presentation explores how innocent feature requests—like adding meetups to a training platform or managing cancellation fees—can quickly lead to leaked domains and tightly coupled microservices. When a generic resource booking service starts querying participant counts to make financial cancellation decisions, it becomes clear that system boundaries have been crossed and team autonomy is compromised.

The turning point occurs when Domain-Driven Design (DDD) principles are applied to rescue the leaking architecture. Instead of designing around rigid use cases, developers must identify stable business concepts. By utilizing "simulations"—hypothetical future scenarios like booking office desks or selling concert tickets—architects can uncover the true nature of their domains. This highlights that a booking capability should act as an open host service, providing a generic resource reservation API rather than use-case-specific endpoints. To ensure scalable architecture, architects must ask three vital questions before designing an API: Which bounded context does the decision belong to? Who will bear the cost of this decision in six months? And does this API increase or decrease team autonomy?

Ultimately, resolving these API design flaws requires aligning technical boundaries with team topologies. Transitioning from siloed component teams to stream-aligned teams utilizing a shared booking platform service clarifies responsibilities and minimizes friction. A classic DDD trap to avoid is pushing business logic into the service that simply holds the data, rather than the service that actually owns the financial or strategic decision. As the system evolves, the goal is not to force heavy architectural machinery upfront, but to practice the true skill of "applying minimal required fragment of complex, deep knowledge exactly at the right moment" to maintain clean, autonomous service boundaries.

**Keywords:** API design strategies, DDD bounded contexts, microservice boundary leakage, software architecture decisions, team topologies, open host service pattern, anti-corruption layer, domain-driven design, JSON API parameters, system capability modeling, resource constraint scheduling, distributed transaction consistency, stream-aligned platform teams, event economics modeling, architectural decision records

## Chapters

1. **Building the initial training planner API** (00:00) — How early system design choices manifest as strategic decisions in API development.
1. **Why cloning services creates architectural duplication** (04:42) — The consequences of forking repositories to support isolated business tickets.
1. **Coupling services to handle cancellation fees** (06:25) — How adding business rules to operational endpoints creates tight coupling and misplaced responsibilities.
1. **Recognizing crossed service boundaries in systems** (10:38) — Understanding the negative impacts of teams making isolated decisions that cross domain boundaries.
1. **Applying domain-driven design principles to APIs** (13:27) — Using bounded contexts and capability layers to evaluate architectural boundaries.
1. **Defining boundaries for planning and booking** (19:08) — Separating the strategic training planner from the operational resource booking context.
1. **Using simulations to test system architecture** (24:09) — Generating hypothetical scenarios to uncover hidden requirements and missing domain concepts.
1. **Prioritizing feature implementations based on cost** (28:05) — Deciding when to support new system capabilities by analyzing likelihood and future complexity.
1. **Making clean architecture decisions iteratively and rapidly** (30:49) — Minimizing delivery overhead by stabilizing small architectural decision records.
1. **Aligning context relations with team topologies** (34:06) — Using the open host service pattern and streamlined teams to clarify API responsibilities.
1. **Modeling event economics and financial logic** (38:42) — Ensuring business logic resides in the service that owns the financial decision, not just the data.

## Related Moments

- [Establishing a concrete vision for REST API development](https://www.wearedevelopers.com/videos/100208-rest-api-antipatterns) (from "Rest API Antipatterns")
- [Understanding the core concepts of API design](https://www.wearedevelopers.com/videos/33-api-design-getting-started) (from "API Design - Getting Started")
- [Summarizing key engineering lessons for platform API development](https://www.wearedevelopers.com/videos/942-insights-from-building-the-canva-developers-platform-to-empower-185-million-designers) (from "Insights from building the Canva Developers Platform to empower 185 million designers")
- [How the inevitable march of time breaks software patterns](https://www.wearedevelopers.com/videos/647-defeat-that-legacy-monster-guerilla-refactoring-with-web-standards) (from "Defeat that legacy monster! Guerilla refactoring with web standards")
- [Structuring engineering teams around domain bounded contexts](https://www.wearedevelopers.com/videos/64-shared-mobility-for-everyone) (from "Shared mobility for everyone!")
- [Building long-term Angular architectures with domain-driven design](https://www.wearedevelopers.com/videos/5-sustainable-angular-architectures-with-nx-and-strategic-design) (from "Sustainable Angular Architectures with Nx and Strategic Design")

## Related Articles

- [Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)](https://www.wearedevelopers.com/magazine/745-why-event-driven-architecture-isn-t-about-speed-and-when-you-actually-need-it)
- [Dev Digest 132 - Binging WADFlix?](https://www.wearedevelopers.com/magazine/473-dev-digest-132-binging-wadflix)
- [How to Avoid Over-Engineering](https://www.wearedevelopers.com/magazine/546-how-to-avoid-over-engineering)
- [Never delegate the understanding](https://www.wearedevelopers.com/magazine/749-never-delegate-the-understanding)

## Related Jobs

- [Principal Software Engineer](https://www.wearedevelopers.com/jobs/ext/267591-principal-software-engineer) at **Twilio**
- [Principal Software Engineer](https://www.wearedevelopers.com/jobs/ext/267587-principal-software-engineer) at **Twilio**
- [Principal Software Engineer](https://www.wearedevelopers.com/jobs/ext/115163-principal-software-engineer) at **Twilio**
- [Principal Software Engineer](https://www.wearedevelopers.com/jobs/ext/146806-principal-software-engineer) at **Twilio**
- [Senior Manager Software Engineering](https://www.wearedevelopers.com/jobs/ext/222930-senior-manager-software-engineering) at **Twilio**
- [Principal Software Engineer, Enterprise AI Platform](https://www.wearedevelopers.com/jobs/ext/1467292-principal-software-engineer-enterprise-ai-platform) at **GitHub**