Bottom-Up System Design through Domain-Centric Transformation
As explained in Part One, the SEDA framework consists of four steps, each of which was briefly discussed. The second step, Bottom-Up System Design through Domain-Centric Transformation, is what we’ll explore in detail in this article and consists of 2 parts:
- System Leverage Points Discovery
- Team Topologies (Re)definition
To be precise, Section 3 outlines the second of four steps in the SEDA framework. This step turns the traditional top-down approach on its head. It focuses on redesigning the company’s team structure based on business domains and leverage points. It takes a bottom-up approach, building on the analysis conducted in the first step.
System Leverage Points Discovery
This step represents a pivotal shift in the SEDA framework; making transformation more intentional, strategic, and aligned with the business logic of the system. It marks the beginning of a bottom-up design process, using Domain-Driven Design to identify key leverage points that can shape both the system and the organization as a whole.
To discover system leverage points, we need to analyze and (re)design our system around business domains and adopt a domain-centric approach in our workflow. This helps organizations enhance team autonomy while reducing their cognitive load. It could be done in 4 steps as following.
Understanding Domain Events as Signals of Business Behavior
Domain events are real, meaningful moments that happen within a business or system; things like Order Placed, Invoice Sent, or Payment Failed. They’re not just technical terms; they represent actual events that matter.
In the context of SEDA, identifying these domain events is the first and most important step. You man ask Why? Because they show how the system truly behaves in the real world, not just how we think it should behave.
EventStorming1, the first tool that we use in this phase to identify domain events, which isn’t just a modeling tool, but a powerful way to bring together a wide range of stakeholders. It’s especially valuable in legacy modernization or complex system transformations, as it helps uncover hidden behaviors of system in some cases2.
Define System Boundaries & Bounded Contexts
Once you’ve identified key domain events through EventStorming, the next step is to translate those events into clear, meaningful boundaries within your system. In complex sociotechnical environments, unclear or overlapping boundaries can cause real problems, confusion, duplicated logic, fragile integrations, and fuzzy ownership.
Defining system boundaries helps separate concerns in a way that reflects both the business logic and the technical structure.
SEDA uses the concept of bounded contexts from Strategic Domain-Driven Design to give these boundaries a clear shape and purpose.
A bounded context is essentially a well-defined section of the system where a specific domain model lives and operates consistently. Inside a bounded context, terms carry precise meaning, rules are applied uniformly, and interactions with other contexts are handled deliberately and explicitly.
Understanding Command-Event Interactions
Once you’ve defined your bounded contexts, the next step in redesigning the system is to map out how action, also known as commands, trigger changes in the system’s state, which are represented as events. In simple terms, a command is just an instruction to carry out a specific operation.Mapping command–event interactions is useful for the following:
To visualize cause-and-effect flows and understand how user intentions translate into observable system reaction.
To define a design and decision-making to which illustrate a clear understanding of how commands trigger events and where those events propagate, architects and teams can rework the system to minimize coordination overhead and maximize autonomy.
Pinpoint the Core Domains as Leverage Points
Not all domains within a system carry the same level of business impact or strategic importance. In the context of SEDA and Domain-Driven Design, core domains are the parts of the system that directly contribute to an organization’s competitive edge.
Recognizing these core domains is crucial because:
- They are where architectural decisions have the greatest impact
- They demand focused and deliberate design effort
- They should be the primary focus for your team’s time and capacity
SEDA proposes that by analyzing patterns uncovered during EventStorming and mapping how commands and events interact across different bounded contexts, we can pinpoint core domains that are highly complex, frequently changing, or closely aligned with key business objectives.
As the complementary of this step, you have to define also other types of domains, supporting and generic, based on definition in Domain-Driven Design.
Team Topologies3 (Re)Definition
Once we’ve explored the system’s current behaviors, structure, and pain points using Domain-Driven Design, the next step in the transformation journey is to reshape the system around its core business domains.
why (Re)Defining Team Structure?
The truth is, whenever we go through a transformation, it’s important to take a fresh look at how we’re organized. Our team topology should evolve alongside our business goals to make sure we’re set up for success. The main reasons traditional team structures need to be changed and redefined are as follows.
High Dependencies Between Teams
Traditional team structures are usually built around specific functions, like front-end, back-end, QA, or infrastructure. While this might seem logical, it often leads to fragmentation across the product development lifecycle.
Slow down delivery due to hand-offs
As work passes between specialized teams, from business analysts to designers, developers, testers, and finally operations, it often hits speed bumps. Each hand-off adds delays, risks miscommunication, and can strip away important context.
Lead to a lack of ownership in critical business areas
When teams are organized by technology or function instead of around business outcomes, no one really owns the full customer journey or value stream. Responsibility gets spread too thin, and accountability becomes unclear.
From Leverage Points to Team (Re)Design
AS we learned in previous section, by identifying key domain events, defining system boundaries, mapping command–event interactions, and highlighting core domains, we begin to form a clear, behavior-driven picture of the system.
This view doesn’t just show how the system works, but it also helps us understand where teams should be placed to support it effectively. Rather than organizing teams around technology stacks or rigid silos, SEDA encourages the use of domain-aligned boundaries as a guide for creating autonomous, stream-aligned teams.
Strategic Team Anatomy Based on Domain Type
Once the domains are categorized as core, supporting, or generic (according to Domain-Driven Design), the Team Topologies model helps map the appropriate team type to each domain effectively.
Core Domains to Stream-Aligned Teams
These are long-standing, cross-functional teams responsible for a product or service from start to finish. Because core domains hold strategic importance, they need teams with deep expertise, strong autonomy, and a clear mission to continuously innovate and deliver value.
Supporting Domains to Enabling Teams
These teams aren’t directly responsible for delivering features, but they play a crucial role in helping other teams succeed. They provide coaching, introduce new capabilities, and tackle cross-cutting concerns. In complex systems, they’re especially valuable, offering guidance and support when core domain teams need help adopting new practices like observability or advanced testing strategies.
Generic Domains to Platform or Complicated-subsystem Teams
These areas provide essential support but don’t set the business apart. Handing them off to platform or outsourced teams helps lighten the mental load on stream-aligned teams, allowing them to concentrate on what really drives value.
Wrapping Up
Bottom-Up System Design through Domain-Centric Transformation represents a pivotal shift in the SEDA approach, moving away from traditional top-down structures toward a model grounded in real-world behaviors.
Instead of treating system architecture and team design as separate challenges, SEDA brings them together through a domain-focused perspective. By paying close attention to how the system actually behaves, through events, decisions, and boundaries, we lay the groundwork for more resilient, autonomous teams that can adapt and thrive.
The four steps for identifying leverage points lay the foundation for strategic redesign as following:
- Identifying key domain events
- Defining system boundaries & bounded contexts
- Mapping command–event interactions
- Pinpointing core domain
Each step offers a unique perspective: events uncover system behavior, boundaries define ownership, interactions highlight dependencies, and core domains help focus priorities.
This domain-centric clarity directly informs how teams should be organized. Using principles from Domain-Driven Design and the structural patterns of Team Topologies, teams can now be aligned with bounded contexts and domain types.
- EventStorming, Alberto Brandolini ↩︎
- In SEDA, we are going to use EventStorming to identify the events that happens within an specific domain. To uncover other types of domain, Systems Thinking will be used in third step of SEDA. ↩︎
- Team Toplogies, Matthew Skelton & Manuel Pais ↩︎
