Introduction: The Data Domain Dilemma
In the world of distributed systems, data is both your greatest asset and your most complex challenge. Traditional monolithic databases create a single point of failure, a bottleneck for teams, and a nightmare for scaling. The brutal truth? Most organizations are drowning in data architecture debt because they've never properly defined their data domains. This isn't just a technical problem—it's an organizational one that impacts velocity, ownership, and ultimately, your ability to deliver value to customers.
Data domains represent bounded contexts where specific data models, business logic, and ownership rules apply. Think of them as sovereign territories within your system landscape, each with its own government (team), laws (business rules), and resources (data). When done right, data domains enable teams to move independently, reduce coupling, and create systems that can actually evolve without requiring a UN-level summit every time someone needs to make a change. When done wrong, you end up with a distributed monolith—all the complexity of microservices with none of the benefits. This guide cuts through the theory and shows you how to actually create data domains that work in production, backed by real-world patterns and anti-patterns I've seen across dozens of organizations.
Understanding Data Domains: Beyond the Buzzwords
A data domain is a logical grouping of data that represents a specific business capability or subdomain, owned by a single team with clear boundaries and interfaces. Let's be direct: this isn't about randomly slicing your database into pieces. It's about identifying natural seams in your business model where data ownership, lifecycle, and access patterns naturally cluster together. The Order domain owns order data. The Inventory domain owns stock levels. The Customer domain owns customer profiles. These aren't arbitrary divisions—they reflect how your business actually operates.
The critical insight here is that data domains must align with your organizational structure following Conway's Law. If your payments team is responsible for payment processing, they should own the Payment domain's data, schema evolution, and access policies. This creates accountability and enables autonomy. Without this alignment, you'll have the worst of both worlds: distributed data stores with centralized decision-making. I've watched teams spend months architecting beautiful domain boundaries only to have them collapse because the org chart looked nothing like the system diagram. The data has to follow the teams, and the teams have to follow the business capabilities.
Each data domain should have its own data store (or at least a logical schema within a shared physical database for transitional architectures). This isn't religious zealotry about "one database per service"—it's pragmatic recognition that shared databases create coupling. When the Pricing team can directly query the Inventory database, you've created an implicit contract that will prevent either team from evolving independently. Yes, this means accepting eventual consistency. Yes, this means more complexity in cross-domain queries. But the alternative is a distributed system in name only, where every schema change requires coordinating with six other teams.
Identifying Your Domain Boundaries: The Discovery Process
Start with Event Storming or Domain Storytelling workshops that bring together engineers, product managers, and domain experts. The goal is to map out your business processes and identify where natural boundaries exist. Look for places where different teams make decisions, where data lifecycles diverge, or where you hear phrases like "that's not our responsibility." These are your domain boundaries trying to emerge. In one e-commerce company I worked with, the breakthrough came when we realized that "inventory" meant completely different things to the warehouse team (physical stock locations) versus the storefront team (available-to-promise quantities). That's two domains, not one.
Use the bounded context pattern from Domain-Driven Design, but don't get lost in the theory. A bounded context is simply an area where a particular model applies. The Customer domain might have a "Customer" entity with email, shipping addresses, and payment methods. The Marketing domain might also have a "Customer" entity, but it's focused on segments, campaign responses, and lifetime value. These are different models serving different purposes, and forcing them into a single shared definition creates the kind of bloated, lowest-common-denominator schemas that make everyone miserable. Let each domain define its own model optimized for its use cases.
# Anti-pattern: Shared Customer model trying to serve everyone
class Customer:
# Identity fields (needed by everyone)
customer_id: str
email: str
# Commerce fields (only relevant to Orders/Fulfillment)
default_shipping_address: Address
payment_methods: List[PaymentMethod]
# Marketing fields (only relevant to Marketing)
segments: List[str]
campaign_preferences: dict
lifetime_value: float
# Support fields (only relevant to Customer Service)
support_tier: str
assigned_rep: str
case_history: List[SupportCase]
# This model is now a bloated mess that changes for the wrong reasons
# Better: Each domain has its own optimized Customer representation
# In the Identity/Auth domain
class CustomerIdentity:
customer_id: str
email: str
auth_credentials: dict
profile_status: str
# In the Commerce domain
class CommerceCustomer:
customer_id: str # Reference to Identity domain
shipping_addresses: List[Address]
payment_methods: List[PaymentMethod]
order_history_summary: dict
# In the Marketing domain
class MarketingProfile:
customer_id: str # Reference to Identity domain
segments: List[str]
campaign_responses: List[CampaignInteraction]
calculated_ltv: float
preferences: MarketingPreferences
# Each domain owns its own model and can evolve independently
Apply the "who asks for the data most often" heuristic. If the Shipping team is constantly querying for delivery addresses while the Marketing team rarely needs them, addresses belong in the Shipping domain (or a shared Customer Profile domain that Shipping depends on). Data gravity matters. Place data close to the team that works with it daily, not the team that occasionally needs a read-only view. The occasional need can be served by events, APIs, or replicated read models. The daily operational needs should drive ownership.
Watch for aggregates—clusters of objects that are always changed together and have a single root entity. In an Order domain, the Order aggregate might include OrderLines, ShippingInfo, and PaymentStatus. These travel together, are modified together, and should live in the same domain. When you see data that's never modified without considering related data, you've found an aggregate boundary. These aggregates become the transactional boundaries in your domain—the unit of consistency that you can guarantee is always in a valid state.
Defining Clear Interfaces: The Contract That Holds Everything Together
Once you've identified domains, the next critical step is defining how they interact. This is where most teams fail. They create domain boundaries in theory but then allow direct database access "just this once" or build synchronous dependencies that couple everything back together. The rule is simple and non-negotiable: domains communicate only through published interfaces—APIs, events, or message queues. Never, ever through direct database access.
For synchronous needs, use REST or gRPC APIs that expose only what other domains need to know. The Order domain doesn't need to know about the internal structure of the Inventory database—it just needs an API call that says "can I reserve 5 units of SKU-12345?" The response is a simple yes/no, possibly with a reservation ID. This creates a contract that the Inventory team can maintain while freely changing their internal implementation. They could move from Postgres to Cassandra, restructure their schema completely, or add caching layers—none of which affects the Order domain as long as the API contract remains stable.
// Order domain code - calling Inventory domain via API
interface InventoryAPI {
checkAvailability(sku: string, quantity: number): Promise<AvailabilityResponse>;
reserveInventory(sku: string, quantity: number, orderId: string): Promise<ReservationResult>;
releaseReservation(reservationId: string): Promise<void>;
}
// The Order domain doesn't know or care about Inventory's internal data model
class OrderService {
constructor(private inventoryAPI: InventoryAPI) {}
async createOrder(items: OrderItem[]): Promise<Order> {
// Check availability for all items
const availabilityChecks = await Promise.all(
items.map(item =>
this.inventoryAPI.checkAvailability(item.sku, item.quantity)
)
);
if (availabilityChecks.some(check => !check.available)) {
throw new Error('Some items not available');
}
// Reserve inventory
const reservations = await Promise.all(
items.map(item =>
this.inventoryAPI.reserveInventory(item.sku, item.quantity, order.id)
)
);
// Create order with reservation references
return this.createOrderWithReservations(items, reservations);
}
}
For asynchronous flows and eventual consistency, use domain events. When a Payment is confirmed, the Payment domain publishes a PaymentConfirmed event. The Order domain subscribes to this event and updates the order status to "paid." The Fulfillment domain also subscribes and begins the picking process. The Accounting domain subscribes and records the revenue. These domains don't directly call each other—they react to facts about what has happened. This decouples them in time and space, making your system dramatically more resilient.
The brutal reality of event-driven architectures: they're harder to reason about and debug than synchronous calls. You can't just follow a stack trace anymore. You need distributed tracing, event logs, and clear event schemas. But the payoff is massive—you can deploy domains independently, scale them independently, and have failures in one domain not cascade to others. When the Recommendation Engine goes down, orders still process. That's the whole point.
Define clear ownership of each interface. The Inventory domain owns the Inventory API and the events it publishes. They're responsible for versioning, backward compatibility, and documentation. If another team needs a new endpoint or field, they submit a request to the Inventory team, who evaluates it against their domain model and roadmap. This prevents the tragedy of the commons where shared APIs become dumping grounds for every team's ad-hoc needs.
Handling Cross-Domain Data: Strategies for the Messy Real World
Here's the uncomfortable truth: some queries genuinely need data from multiple domains. The "Customer Order History" view needs data from Customer, Order, Payment, and Fulfillment domains. You have several options, each with tradeoffs: API composition, CQRS with replicated read models, or API gateway-level aggregation. There's no silver bullet—choose based on your consistency requirements, query patterns, and team capabilities.
API composition is the simplest approach—the client (or a Backend for Frontend layer) makes multiple API calls and stitches the results together. Fetch customer info from the Customer API, fetch orders from the Order API, fetch shipment status from the Fulfillment API, then combine them in memory. This works for low-volume, user-initiated queries where a few hundred milliseconds of latency is acceptable. It doesn't work for high-volume analytical queries or cases where you need strong consistency across domains.
// API Composition pattern in a BFF (Backend for Frontend)
class CustomerOrderHistoryService {
constructor(
private customerAPI: CustomerAPI,
private orderAPI: OrderAPI,
private fulfillmentAPI: FulfillmentAPI
) {}
async getCustomerOrderHistory(customerId: string): Promise<OrderHistory> {
// Make parallel calls to different domains
const [customer, orders, fulfillments] = await Promise.all([
this.customerAPI.getCustomer(customerId),
this.orderAPI.getOrdersByCustomer(customerId),
this.fulfillmentAPI.getShipmentsByCustomer(customerId)
]);
// Compose the data in memory
const enrichedOrders = orders.map(order => {
const shipment = fulfillments.find(f => f.orderId === order.id);
return {
...order,
customerName: customer.name,
shippingStatus: shipment?.status,
trackingNumber: shipment?.trackingNumber
};
});
return {
customer: customer,
orders: enrichedOrders
};
}
}
CQRS (Command Query Responsibility Segregation) with replicated read models is more sophisticated. Each domain publishes events about state changes. A separate read model service subscribes to these events and builds optimized, denormalized views specifically for queries. The "Customer Order History" read model subscribes to CustomerUpdated, OrderPlaced, OrderShipped events and maintains a single, query-optimized table. Queries hit this read model, not the source domains. The tradeoff: eventual consistency (the read model might be slightly stale) and additional complexity maintaining these projections.
# CQRS Read Model approach
class OrderHistoryReadModel:
"""
Subscribes to events from multiple domains and maintains
a denormalized view optimized for the Order History query
"""
def __init__(self, event_bus, database):
self.db = database
# Subscribe to relevant events
event_bus.subscribe('CustomerUpdated', self.handle_customer_updated)
event_bus.subscribe('OrderPlaced', self.handle_order_placed)
event_bus.subscribe('OrderShipped', self.handle_order_shipped)
event_bus.subscribe('PaymentConfirmed', self.handle_payment_confirmed)
def handle_customer_updated(self, event):
# Update customer info in the read model
self.db.execute("""
UPDATE order_history_view
SET customer_name = %s, customer_email = %s
WHERE customer_id = %s
""", (event.name, event.email, event.customer_id))
def handle_order_placed(self, event):
# Insert new order record
self.db.execute("""
INSERT INTO order_history_view
(order_id, customer_id, order_date, total_amount, status)
VALUES (%s, %s, %s, %s, 'pending')
""", (event.order_id, event.customer_id, event.order_date, event.total))
def handle_order_shipped(self, event):
# Update shipping status
self.db.execute("""
UPDATE order_history_view
SET status = 'shipped', tracking_number = %s, shipped_date = %s
WHERE order_id = %s
""", (event.tracking_number, event.shipped_date, event.order_id))
# The read model is eventually consistent but optimized for queries
def get_customer_order_history(self, customer_id):
return self.db.query("""
SELECT * FROM order_history_view
WHERE customer_id = %s
ORDER BY order_date DESC
""", (customer_id,))
For reference data that rarely changes (like product catalogs or customer names), consider selective replication. The Order domain can cache customer names locally, refreshing them when it receives CustomerUpdated events. This lets you display "Order placed by John Smith" without calling the Customer API on every query. Just be aware that the name might be slightly stale if John changed it to "John P. Smith" recently. For most use cases, this staleness is acceptable—the business can tolerate showing the old name for a few minutes.
The worst approach is creating a "shared database" for cross-cutting concerns. I've seen teams create a "reporting database" that every domain writes to directly. This recreates all the coupling problems you're trying to solve. If you need a unified view for reporting, use event-driven replication into a data warehouse or analytics platform—but keep the operational domains independent. Your OLTP (transactional) systems and OLAP (analytical) systems serve different purposes and should be architected differently.
Managing Data Evolution: Versioning and Migration in a Distributed World
Schemas will change. APIs will evolve. This is inevitable. The question is whether these changes break half your system or proceed smoothly. The key is treating every interface as a contract with explicit versioning and backward compatibility guarantees. When the Customer domain adds a new field to their API response, existing clients shouldn't break. When they deprecate a field, there should be a clear migration path and timeline.
Use semantic versioning for your APIs (1.0, 1.1, 2.0) and follow the principle that minor versions add features while maintaining backward compatibility, while major versions can include breaking changes. In practice, this means: always make fields optional when adding them, never remove required fields without a major version bump, and maintain multiple API versions simultaneously during transition periods. Yes, this is more work. The alternative is coordinating simultaneous deployments across dozens of services every time a schema changes.
// Version 1.0 of Customer API response
interface CustomerV1 {
id: string;
email: string;
name: string;
}
// Version 1.1 - added optional phone field (backward compatible)
interface CustomerV1_1 extends CustomerV1 {
phone?: string; // Optional, so existing clients don't break
}
// Version 2.0 - split name into firstName/lastName (breaking change)
interface CustomerV2 {
id: string;
email: string;
firstName: string;
lastName: string;
phone?: string;
// Deprecated: name field removed
}
// API versioning in practice
class CustomerAPIGateway {
// Support multiple versions simultaneously
async getCustomer(id: string, version: string): Promise<CustomerV1 | CustomerV2> {
const customerData = await this.customerRepo.findById(id);
if (version === '2.0') {
return {
id: customerData.id,
email: customerData.email,
firstName: customerData.firstName,
lastName: customerData.lastName,
phone: customerData.phone
};
} else {
// Version 1.x - map new format back to old format
return {
id: customerData.id,
email: customerData.email,
name: `${customerData.firstName} ${customerData.lastName}`,
phone: customerData.phone
};
}
}
}
For events, include a schema version in every event. Use schema registries like Confluent Schema Registry or AWS Glue Schema Registry to manage event schemas centrally. Consumers can then validate incoming events against the expected schema and handle different versions appropriately. When you publish a new event version, keep producing the old version for a transition period, or provide clear upgrade documentation for consumers.
Database migrations within a domain are the owning team's responsibility. They should use tools like Flyway, Liquibase, or Alembic to version control their schema changes and apply them automatically during deployments. The critical rule: migrations must be backward compatible with the previous version of the application code. Deploy in blue-green fashion: apply schema changes that are compatible with both old and new code, deploy new code, then optionally apply cleanup migrations that remove deprecated columns. This lets you roll back code deploys without database rollbacks, which are always painful.
For cross-domain impacts, use the Expand-Contract pattern. When changing how two domains interact: first expand (add the new interface while keeping the old one), then migrate consumers to the new interface, then contract (remove the old interface). If the Payment domain wants to change how they notify the Order domain about payment confirmation, they'd first add the new event type while continuing to publish the old one, wait for the Order domain to update their consumer to handle the new format, then stop publishing the old event. This phased approach prevents the "everything breaks at once" scenario.
Implementation Patterns: From Monolith to Domains
If you're starting from a monolithic database, don't try to split everything at once. That's a recipe for disaster. Use the Strangler Fig pattern—gradually extract domains one at a time, building new functionality in the new architecture while leaving the old system running. Start with the domain that has the clearest boundaries and the least coupling to the rest of the system. In most e-commerce companies, the Product Catalog or Customer Reviews are good starting points—they're relatively independent and have clear ownership.
Create an anti-corruption layer that translates between the old monolith and the new domain. This might be a service that reads from the old database but exposes a clean API and events for the new architecture. Over time, you migrate the actual data ownership, but the anti-corruption layer means the rest of your new architecture doesn't have to know about the messy legacy system. This is pragmatic evolution, not big-bang rewriting.
# Anti-Corruption Layer - shields new domain from legacy monolith
class LegacyCustomerAdapter:
"""
Adapts the legacy monolithic database to the new Customer domain API.
Allows gradual migration without forcing all consumers to understand legacy schema.
"""
def __init__(self, legacy_db, event_publisher):
self.legacy_db = legacy_db
self.event_publisher = event_publisher
def get_customer(self, customer_id: str) -> CustomerV2:
# Read from legacy database with its messy schema
legacy_data = self.legacy_db.query("""
SELECT c.cust_id, c.email, c.full_name, c.phone_number,
a.street, a.city, a.state, a.zip
FROM customers c
LEFT JOIN customer_addresses a ON c.cust_id = a.cust_id
WHERE c.cust_id = %s AND a.is_default = true
""", (customer_id,))
# Transform to clean domain model
name_parts = legacy_data['full_name'].split(' ', 1)
return CustomerV2(
id=str(legacy_data['cust_id']),
email=legacy_data['email'],
firstName=name_parts[0],
lastName=name_parts[1] if len(name_parts) > 1 else '',
phone=legacy_data['phone_number']
)
def update_customer(self, customer: CustomerV2) -> None:
# Write to legacy database
self.legacy_db.execute("""
UPDATE customers
SET email = %s, full_name = %s, phone_number = %s
WHERE cust_id = %s
""", (customer.email,
f"{customer.firstName} {customer.lastName}",
customer.phone,
customer.id))
# Publish domain event so new services can react
self.event_publisher.publish(CustomerUpdated(
customer_id=customer.id,
email=customer.email,
firstName=customer.firstName,
lastName=customer.lastName
))
Use database views or logical schemas as an intermediate step. Before physically separating databases, you can create separate schemas (e.g., customer_domain, order_domain) within the same database instance. Enforce that each service only connects to its own schema. This gives you domain isolation without the operational overhead of managing multiple database instances. Once teams are comfortable operating independently, you can migrate to separate physical databases with minimal disruption.
Consider using a data mesh approach for larger organizations. In data mesh, each domain not only owns its operational data but also publishes curated data products for analytical use. The Order domain maintains its transactional order database but also publishes an "Orders Data Product" with cleaned, aggregated data for the data warehouse. This shifts the burden of data quality and documentation to the domain teams who understand the data best, rather than centralizing it in a data engineering team that's always playing catch-up.
The 80/20 Rule: Critical Actions for Maximum Impact
You don't need perfect domain boundaries from day one—you need good enough boundaries that you can evolve. Here's the 20% of work that delivers 80% of the value in creating data domains. First, identify your three most critical business capabilities. In most companies, these cluster around core revenue operations—orders, payments, fulfillment for e-commerce; claims, policies, underwriting for insurance; listings, bookings, reviews for marketplaces. These become your first three domains. Get these right and you've handled the majority of your data complexity.
Second, enforce the "no direct database access" rule religiously from the start, even if domains share a physical database initially. Create service APIs or database views that mediate all cross-domain access. This rule alone prevents 80% of the coupling issues that plague distributed systems. When a team wants to query another domain's data, make them submit an API request. The friction is intentional—it forces conversations about whether the coupling is necessary and how to minimize it.
Third, implement event publishing for state changes in your domains, even if no one is subscribing yet. When an Order is placed, publish an OrderPlaced event. When a Payment is confirmed, publish PaymentConfirmed. This creates the connective tissue for async communication without requiring every team to refactor simultaneously. New features can subscribe to these events, gradually moving you toward event-driven architecture. Events are your escape hatch from synchronous coupling.
Fourth, assign clear ownership. Every domain needs an accountable team—not a committee, not a shared responsibility, but a specific team that owns the schema, the API, the service level objectives, and the evolution roadmap. When something breaks, everyone knows who to call. This organizational clarity matters more than technical perfection. I've seen elegant domain models fail because no one would make decisions, and crude domain models succeed because teams owned them completely.
Fifth, start with coarse-grained domains and split later if needed. It's much easier to split a domain that's gotten too big than to merge domains that are too small. If you're debating whether Customer Profile and Customer Preferences are separate domains, start with one. If the team becomes overwhelmed or the models start diverging significantly, split them then. Premature decomposition creates a communication overhead that kills velocity. Wait for the pain before adding complexity.
Key Takeaways: Making Data Domains Work
Here are the five non-negotiable principles for successful data domain implementation. One: align domains with business capabilities and team ownership. Your system architecture must mirror your organizational structure. If your domain boundaries don't match your team boundaries, one of them is wrong. Fix the mismatch or accept that you're building a distributed monolith.
Two: domains communicate only through published interfaces—never through direct database access. This is the load-bearing wall of domain independence. Every exception you make weakens the entire structure. API calls for synchronous needs, events for asynchronous flows, replicated read models for queries. The moment you allow "just one" service to query another domain's database, you've created coupling that will prevent independent evolution.
Three: accept eventual consistency as a feature, not a bug. The real world is eventually consistent—your bank account balance isn't updated instantaneously across all systems the moment you make a purchase. Your distributed system can embrace the same reality. This requires rethinking your transaction boundaries and being honest about what actually needs strong consistency (very little) versus what can tolerate seconds or minutes of staleness (most things).
Four: version everything and maintain backward compatibility. APIs, events, schemas—all need explicit versions and a commitment to not breaking existing consumers without a migration path. The tax you pay for distributed systems is the discipline of treating every interface as a contract. This isn't optional. Systems that don't version rigorously end up with coordinated releases across dozens of services, eliminating the independence you're trying to create.
Five: evolve gradually using the Strangler Fig pattern. Don't try to redesign your entire data architecture in one big bang. Extract one domain at a time, starting with the most clearly bounded and least coupled. Use anti-corruption layers to shield new domains from legacy systems. Build new features in the new architecture while maintaining the old system. Over months or years, the new architecture strangles the old. This requires patience and executive support—you're investing in long-term architectural health at the cost of short-term feature velocity.
Analogies and Mental Models for Domain Thinking
Think of data domains as countries with borders. Each country has sovereignty over its territory (data), makes its own internal decisions (schema, storage technology), and controls its borders (APIs). Other countries can't just walk in and take your resources—they have to go through customs (API calls). Countries trade with each other (events and API contracts), but each maintains independence. When France changes its tax law, Germany doesn't break. Your domains should work the same way.
Another useful mental model: data domains are like organs in a body. The heart (Payment domain) has a specific job and its own local rules. The lungs (Inventory domain) have a different job with different rules. They communicate through well-defined interfaces—the circulatory system for the heart, the respiratory system for the lungs. You can't just bypass these interfaces and have the heart directly manipulate lung tissue. The body works because organs are specialized, bounded, and communicate through standard interfaces. Your system needs the same specialized, bounded components with standard communication pathways.
Consider the concept of a domain as a "bounded context"—like a language boundary in the real world. The word "bank" means something different in financial services (a place to store money) versus river management (the edge of a river). Both are correct in their context. Similarly, "Customer" means something different in your Marketing domain (a segment and set of behaviors) versus your Support domain (a person with problems to solve). Don't try to force a single definition across contexts. Let each domain define terms in ways that make sense for their purpose.
The "local autonomy, global coordination" principle from team management applies perfectly to data domains. Each team (domain) should have maximum freedom to make local decisions about implementation details—what database technology to use, how to structure their schema, how to optimize their queries. But they must coordinate on the interfaces and contracts that affect other teams. This mirrors how effective organizations work: teams have autonomy within their area but coordinate on cross-cutting concerns.
Finally, think about data domains like city planning zones. You don't put a steel factory in a residential neighborhood. Each zone has specific allowed uses, building codes, and regulations. The residential zone (Customer domain) has different rules than the industrial zone (Order Processing domain). But they're all part of the same city (overall system) and need infrastructure connecting them (API gateway, message bus). Good zoning prevents conflicts and enables each area to optimize for its purpose without interfering with others.
Conclusion: The Long Game of Domain Architecture
Creating effective data domains isn't a six-month project with a clear end date—it's a continuous architectural practice that evolves with your business. The organizations that succeed are those that treat domain boundaries as first-class architectural concerns, invest in the tooling and practices to maintain them, and have the discipline to say no to shortcuts that create coupling. This requires executive buy-in, because you're trading short-term feature velocity for long-term architectural health. Make that tradeoff explicit.
The brutal truth I've learned from watching dozens of domain architecture initiatives: about half fail not because of technical challenges but because of organizational resistance. Teams don't want to coordinate across APIs when they could just query a database directly. Product managers don't want to hear that a feature requires cross-team negotiation. Executives don't understand why everything takes longer now. You need to manage this change carefully, show incremental value, and celebrate the wins—independent deployments, faster feature delivery within domains, reduced outages from coupling. The technical work is actually the easy part. The hard part is changing how people work together. Start there, and the technical patterns will follow. Get domains wrong, and you'll have all the complexity of distributed systems with none of the benefits. Get them right, and you'll have an architecture that can actually evolve with your business.