DEV Community: Ajinkya Ashokrao Pawar

Your Code Is Lying to You: Domain-Driven Design Is the Truth Serum

Ajinkya Ashokrao Pawar — Fri, 27 Feb 2026 05:08:39 +0000

I was once in a war room at 2 AM with five engineers, three energy drinks, and a whiteboard full of arrows nobody could follow. A critical bug had happened. An order was placed, payment went through, inventory was reduced, but the shipment never started.

We had microservices, Kafka, Redis caches, circuit breakers, and distributed tracing that cost a small fortune. What we did not have was a shared idea of what an “Order” actually meant in our system.

The payment service had its own Order. Inventory had another. Shipping had a third. They all had the same name, but they all disagreed in small ways that added up to a big problem.

That night made one thing clear to me. The code was not the main problem. The language we used, the words and meanings we shared, was the real issue.

The Lie Teams Tell Themselves

Most teams believe this story: "If we get the architecture right, the business logic will fit in." It never does.

You can build a perfect service layout, follow deploy best practices, and still fail when the business changes a single definition. If finance changes what “revenue recognition” means, and that concept is scattered across the system in slightly different forms, you will end up rewriting many parts of the system.

The problem is not technology alone. It is communication. Databases and APIs are only the medium for a conversation. If everyone uses the same words to mean different things, you get bugs and late-night debugging sessions.
Domain-Driven Design, or DDD, is a way to make that conversation honest.

What DDD Really Is

DDD is not just a list of patterns to copy. It is not enough to add Aggregates, Repositories, or a domain folder and call it done. Those are tools, not the point.

At its heart, DDD says this: the code should reflect how the business thinks about its domain. The model in your code should match the model in the heads of the people who run the business.

From that idea come the tactical pieces: Entities, Value Objects, Aggregates, Domain Events, Repositories, and so on. Use the patterns only after you have real domain understanding. Otherwise the patterns are just decoration.

Start by Talking to the Right People

This step feels untechnical, so books often skip it. It is the most important step.

Find the real domain experts, the people who do the work every day. Let them walk you through their work. Ask how they handle edge cases. Listen to the words they use.

When a logistics person says “dispatch the order” and your code has a method named sendOrder(), that's a warning sign. Every developer now carries a translation layer in their head between business language and code. That translation is where misunderstandings and bugs live.

Use a shared vocabulary, a Ubiquitous Language, that everyone uses in conversations, documentation, and code. If the business uses the word “Quote”, “Policy”, and “Coverage” as distinct concepts, your code should use those same names, not squeeze them into a single Policy object with a status field.

Bounded Contexts: Where Language Stays Honest

Once you have a shared vocabulary, ask where it applies. Different parts of the business may use the same word for different things. That is normal.

A Bounded Context is a clear boundary where a specific model and its language are consistent. Outside that boundary, the same word can mean something else.

For example, “Product” means different things to different teams:

Catalog: attributes, images, categories, variants.
Inventory: SKU, quantity, warehouse location.
Pricing: price rules, promotions, cost.
Shipping: weight, dimensions, freight class.

Trying to make one giant Product model that serves all teams creates a fragile, bloated thing that everyone must touch. Instead, accept that these are separate models and own them in their own contexts: CatalogProduct, InventoryItem, PricePoint, ShippableItem.

Yes, this adds integration work. But the cost of hiding that complexity inside a shared model is higher and more dangerous.

Map the Contexts

After you identify bounded contexts, draw a Context Map. This is not a technical diagram. It is a strategic one.

The map shows which contexts exist, how they communicate, and who sets the terms of each integration. That last point matters. If two teams both think they are upstream, integrations will fail. Decide who publishes the canonical model, who adapts to it, and where you need translation layers or Anti-Corruption Layers (ACL).

A two-hour session to draw the map often beats weeks of design documents.

Aggregates: Focus on Consistency

An Aggregate groups domain objects that must be changed together inside a single transaction. The aggregate root is the only object external code holds a reference to.

The key idea is transactional consistency: you can only guarantee consistency within an aggregate in a single transaction. Work that spans aggregates should be eventually consistent and coordinated with events.

We once had an enormous Order aggregate that included line items, address, payment, and promotions. It locked and slowed everything. When we split payment into its own aggregate and used events to coordinate, contention dropped and the code became clearer. Use aggregates to express what truly needs to be consistent in one step.

Domain Events: The Nervous System

Domain events record something that happened in the domain. They are past-tense, business-focused names: OrderPlaced, PaymentConfirmed, InventoryReserved, ShipmentDispatched.

Domain events let bounded contexts communicate without tight coupling. When Order publishes OrderPlaced, Inventory can reserve stock, Notifications can send emails, and Fraud can check risk, each on its own schedule.

This gives you real decoupling. If a service is down, events remain durable in a broker and are processed when it recovers. No lost triggers, no frantic 2 AM debugging.

Anti-Corruption Layers: Keep Your Model Clean

When you integrate with external systems, you risk letting their models leak into yours. Small changes at the edge can slowly contaminate your domain.

An Anti-Corruption Layer (ACL) is a translation boundary. Convert the external model into your own domain language at the edge. Keep your internal model pure and expressed in your ubiquitous language.

If you use Stripe, do not let StripePaymentIntent flow through your domain. Translate Stripe responses into your PaymentAttempt or Payment objects before they touch your core logic.

Use Event Storming for Discovery

Event Storming is a fast, collaborative workshop format to discover domain events, commands, actors, and policies. It uses stickies or virtual notes to map what happens and why.

Start with events, things the business cares about, and put them in time order. Add commands, actors, external systems, and policies. Look for disagreements and hotspots. Those are where design and conversations should focus. I have seen Event Storming sessions reveal fundamental misunderstandings in a few hours that had hidden in code for months.

This Is Hard, and That Is Okay

DDD is not a quick fix. It takes discipline, time, and humility. Engineers must listen more than lecture. Organizations may need to adjust team boundaries. Conway’s Law is real: your architecture will reflect how your teams communicate.

DDD is not always the right tool. For simple CRUD apps, it may add overhead. But when business rules are complex, change frequently, or errors are costly, DDD pays off.

How to Start Tomorrow

Pick one confusing concept in your domain. Meet the relevant domain expert for an hour. Listen to the words they use. Compare those words to your code. Change one class, one method name, or one database column to use the right language. Notice how the conversation changes.

DDD is practice, not a project you finish. Over time, your code should become a clearer reflection of how the business thinks.

The Goal

Great architecture is not the most technically fancy architecture. It is the architecture where the code tells the truth about the business.

When a new engineer can read the code and understand how the business works, that is success. When a domain expert looks at a diagram and says, “Yes, that is how we think,” that is DDD working.

Build that, and the rest becomes an implementation detail.

The Microservices Hangover: Why 2026 Is the Year of the Sovereign Module

Ajinkya Ashokrao Pawar — Mon, 09 Feb 2026 11:31:52 +0000

For years, microservices were the automatic answer to every architectural problem. Break the monolith. Split everything into services. Add an API gateway. Add a service mesh. Add observability. Repeat.

It worked in some cases. It also created a lot of hidden complexity.

Now in 2026, something is changing. The pressure on our systems is no longer just about scaling traffic or speeding up deployments. It is about building systems that AI agents can navigate and reason about. That shift exposes weaknesses in how many of us designed systems over the last decade.

This is where the idea of a Sovereign Module starts to make sense.

What is a Sovereign Module?

It is not a return to the old "spaghetti" monolith. It is not anti-microservices. It is a move toward building larger, coherent architectural units where data and behavior live together in a way that makes reasoning easier for both humans and machines.

1. The Context Problem: Fragmented Intelligence

Microservices optimized for decoupling. Each domain had its own service and often its own database. That made teams independent, but it fragmented context.

When an AI agent interacts with a system in 2026, it tries to understand relationships. It asks cross-domain questions. In a heavily fragmented architecture, answering a simple business question can require calls to 15 different services.

What used to be a network tax is now a reasoning tax.

A Sovereign Module groups related capabilities into a coherent unit. When data and logic live closer together, reasoning—whether by a junior dev or an LLM—becomes simpler and faster.

2. The Hidden Cost of Intelligence

There is a shift people don't talk about enough: The cost of inference.

Before, the cost of a request was mostly compute and memory. Now, many systems include model-based validation or transformation at every hop.

Traditional: Service A → Service B → Service C (Cheap network calls)
2026: Service A (AI check) → Service B (AI check) → Service C (AI check)

In a distributed setup, the latency and dollar cost of these model evaluations add up quickly. By reducing hops and moving toward "Sovereign" units, you minimize the number of times you need to cross a network boundary to gather context.

3. From Fixed Workflows to Flexible Execution

Traditional architectures are built around fixed paths: A -> B -> C.
Modern AI-driven systems rely on orchestration layers that decide dynamically how to fulfill a request. If your system is a collection of 50 tiny, fragile services, the AI coordinator will struggle to maintain state and reliability.

Sovereign Modules help because they expose stable domain capabilities rather than thin technical endpoints.

Feature	Microservices (The 2020 Era)	Sovereign Modules (The 2026 Era)
Primary Goal	Independent Scaling	Context Coherence
Data Strategy	Database-per-service (Fragmented)	Bounded Data Locality
Communication	Deep chains of API calls	Cohesive internal execution
AI Readiness	Low (High Reasoning Tax)	High (Context-Rich)

4. The Practical Reset: How to Move Forward

The shift away from extreme microservices is not about going backwards; it’s about correcting over-engineering. If you are feeling the "hangover," here is the 2026 playbook:

Merge services that always change together: If you can't update Service A without touching Service B, they aren't decoupled; they are just separated by a slow network.
Strengthen boundaries, not service counts: Focus on logical isolation within a module before physical isolation across the network.
Data Locality over Granularity: Treat your data model as a strategic asset. If an AI agent needs it to make a decision, it should be easily accessible, not buried behind three layers of REST APIs.

Build for Clarity

The systems that will survive the next decade are not the ones with the most impressive, complex diagrams. They are the ones that are coherent.

The conversation is no longer "Monolith vs. Microservices." It is about Coherence vs. Fragmentation. Trends come and go, and complexity always accumulates. But in the age of AI, clarity scales much further than hype ever will.

The Hidden Cost of “Event-Driven Everything”: Why Most Systems Don’t Need Kafka (Yet)

Ajinkya Ashokrao Pawar — Mon, 09 Feb 2026 10:51:32 +0000

Over the past decade, event-driven architecture (EDA) has quietly shifted from being a specialized design choice to becoming a default recommendation. Teams adopt Kafka before they define domain boundaries. Architects propose asynchronous workflows before validating throughput requirements.

“Event-driven” has become synonymous with “modern.” That shift deserves scrutiny.

Event-driven systems are powerful. They enable decoupling, scalability, replayability, and cross-domain integration. But these benefits emerge only under specific conditions. Outside of those conditions, the complexity introduced often outweighs the value delivered.

The question is not whether EDA works. It clearly does. The real question is whether your system genuinely requires it.

1. The Mismatch Between Problem and Solution

In many organizations, asynchronous messaging is introduced as a form of future-proofing. The assumption is that scaling challenges will inevitably arise, and building with Kafka from day one prevents expensive rewrites later.

This logic is appealing but flawed.

Architecture should optimize for present constraints while preserving the ability to evolve. Introducing distributed streaming infrastructure into a low-to-moderate throughput system creates operational overhead without proportional benefit. Most early-stage platforms, internal systems, and CRUD-centric SaaS products simply do not have the event volume or domain fragmentation that justifies a streaming backbone.

Adding infrastructure ahead of need is not foresight. It is speculative complexity.

2. Cognitive Overhead and the Debugging Reality

Synchronous systems fail in visible ways. A request times out. An exception propagates. Observability is straightforward.

Event-driven systems fail in temporal fragments:

A producer succeeds while a consumer fails.
Retries mask systemic issues until they explode.
Dead-letter queues (DLQ) accumulate unnoticed.
State divergence surfaces minutes (or hours) later.

Debugging becomes temporal reconstruction. You are no longer tracing a call stack; you are reconstructing distributed causality across logs and timestamps. This demands:

Disciplined correlation IDs
Idempotent handlers
Schema governance
Distributed tracing

Without high operational maturity, these aren't "nice-to-haves"—they are survival mechanisms.

3. Eventual Consistency vs. Business Semantics

Event-driven architectures frequently rely on eventual consistency. In production, this translates into transient data divergence:

Inventory counts may not immediately reflect purchases.
Financial aggregates may lag behind transactions.
User-facing dashboards display stale state.

If the business domain cannot tolerate temporary inconsistency, the architecture must compensate with additional coordination mechanisms. That coordination usually destroys the very "simplicity" that EDA promised.

4. Operational Complexity Is Not Linear

Running a distributed streaming platform is materially different from exposing REST endpoints. You have to account for:

Concept	The Tax
Partitioning	Affects ordering guarantees and throughput.
Rebalancing	Can cause latency spikes and "stop-the-world" consumer pauses.
Exactly-once	Often degrades to at-least-once, requiring idempotent logic everywhere.
Storage	Broker stability is directly tied to disk and retention management.

When is EDA Justified?

There are environments where event-driven architecture is not optional:

High-volume transactional systems.
Real-time analytics pipelines.
IoT ingestion layers.
Financial transaction processing.

In these cases, Kafka isn't architectural fashion—it’s infrastructure necessity.

A Pragmatic Evolution Path

The most resilient architectures follow a predictable progression:

Modular Monolith: Invest in clear domain boundaries first.
Synchronous Services: Extract services only where scaling pressures emerge.
Targeted Asynchrony: Introduce messaging for specific, high-value use cases (e.g., sending emails, generating reports).
Full Event-Driven Ecosystem: Only when cross-domain workflows justify the tax.

Final Thought: Architecture is Trade-off Management

The industry’s tendency to equate complexity with sophistication distorts decision-making. A well-structured synchronous system that is understandable, observable, and operable will outperform an over-engineered asynchronous system in most environments.

Clarity scales farther than abstraction.

The mature architectural question is not "How do we make this event-driven?" It is "What specific constraint are we solving, and what cost are we accepting in return?"

Latency Is Not a Performance Problem. It Is a Design Problem.

Ajinkya Ashokrao Pawar — Wed, 28 Jan 2026 11:22:03 +0000

For more than twenty years the industry has treated latency as something to optimize. Faster CPUs. Better frameworks. Smarter garbage collectors. More aggressive caching. Parallel execution. Async everywhere.

Yet systems still feel slow.

This happens because latency is not primarily a performance problem. It is a design problem that performance tools cannot fix.

Performance assumes the system shape is correct and execution is inefficient. Latency appears when the system shape itself forces waiting. Once waiting exists in the design, no amount of optimization removes it. You can only hide it.

Distributed systems do not fail because components are slow. They fail because time is forced to flow through too many places.

Why latency compounds across services

In a monolithic system a function call is cheap. Memory is shared. Execution remains inside a single scheduler. Time mostly behaves.

In distributed systems every boundary introduces waiting. A service call is not a method call. It is a negotiation between machines. Before a single line of business logic executes, the system must perform:

Thread scheduling and kernel transitions.
Serialization and deserialization.
Network buffering and TCP flow control.
Routing and remote queuing.

None of this is free. When several services are chained, latency compounds-not additively, but statistically.

Percentiles do not compose. If five services each have a p95 latency of 40ms, the combined request is not 200ms. The slowest tail dominates. One cold cache or one GC pause decides the outcome for the whole chain. This is why systems appear fast in metrics but feel slow in reality.

Microservices did not create latency. They exposed it.

Latency existed long before microservices; monoliths simply hid it inside memory calls. Microservices externalized it.

Every design shortcut that once lived quietly inside a codebase became observable across the network. Tight coupling turned into synchronous dependencies. Over-normalized logic turned into chatty communication.

Microservices did not make systems slower. They made architectural mistakes measurable.

Why async does not fix latency

Async improves throughput. It does not reduce time.

If a remote call takes 120ms, making it asynchronous does not make it faster. It only allows the thread to do something else while waiting. The wall clock still moves at the same speed. Async changes who waits. It does not remove waiting.

Most systems still contain a synchronization point where all required data must be available before responding. That moment defines perceived latency. Everything before it is irrelevant.

Fan out: The most dangerous latency pattern

Fan out is seductive. One request becomes many parallel calls with aggregation at the end. On diagrams, this looks scalable. In reality, response time becomes equal to the slowest downstream dependency.

At scale, something is always slow. A network jitter, a hot shard, or a thread pool briefly exhausted. When a request fans out to ten services, you are designing for tail latency amplification.

This is why mature systems aggressively collapse reads, precompute views, and accept duplication. They do it because latency is more expensive than redundancy.

Humans perceive latency before machines measure it

Machines measure latency numerically. Humans experience it neurologically:

100-150ms: Interaction stops feeling instantaneous.
300ms: Delay becomes noticeable.
1 second: Cognitive flow breaks.
2-3 seconds: Trust begins to erode.

A backend team may celebrate a 250ms p95, but users already feel friction. Latency is not just time-it is a loss of agency.

The request path is sacred

Latency rarely comes from language choice. It comes from synchronous dependency chains and computing truth during the request instead of before it.

Fast systems move work out of the request path. They compute earlier. They cache aggressively. They pre-join data. They accept eventual consistency deliberately. The oldest rule still holds: You can be correct or you can be fast.

If a system must compute truth at the moment a human is waiting, the system is already late. The heavy thinking should have already happened. The request should be retrieval, not discovery.

Conclusion: Design Short, Not Fast

Junior thinking asks how to make this faster. Senior thinking asks why this request exists at all.

Latency drops most when work is removed, not accelerated. The fastest network call is the one never made. The fastest query is the one computed yesterday.

Latency is not a bug. It is feedback. It tells you where your system is thinking too late. Once you see that difference, you stop fighting latency.

You design around it.

When Over-Engineering Actually Makes Sense (And How to Know You’re There)

Ajinkya Ashokrao Pawar — Sat, 24 Jan 2026 20:18:28 +0000

In my last post, I warned about the hidden cost of building too much too early. But not all over-engineering is wrong. Sometimes, complexity is justified. The trick is knowing when and why.

I’ve learned that the line between premature abstraction and necessary architecture isn’t fixed-it’s contextual. Here’s how to tell the difference.

1. You have real, repeatable pain points

Premature complexity is invisible. You imagine future traffic, future features, future integrations-none of which exist yet. Necessary complexity emerges from repeated, actual problems.

For example, in a Spring Boot system I worked on, our messaging flow was initially one service handling all notifications: email, push, and SMS. At first, it was simple. But as soon as user count doubled, each channel needed retries, monitoring, and rate-limiting. That one service became a bottleneck for everything.

Adding abstraction layers at that point-separate services, event-driven delivery, and backoff policies-reduced pain instead of creating it. If the complexity solves problems that are recurring, you’ve crossed the line from “premature” to “necessary.”

2. You can reason about it without fear

When a developer can trace a flow from end to end, even with multiple layers or services, complexity is manageable.

A healthy mental diagram looks like this:
Client -> API Gateway -> Controller -> Service -> Event Publisher -> Consumer -> Database

If each layer has a clear purpose, is testable, and is predictable, the system isn’t over-engineered-it’s resilient. If developers "freeze" when reading the code or are afraid to touch a module because they don't know what it will break, it’s likely still premature or poorly abstracted.

3. You have real scaling or regulatory constraints

Early-stage apps rarely need extreme scalability. However, there are "Hard Requirements" that justify complexity immediately:

High Throughput: Hundreds of concurrent writes per second.
Sensitive Integrations: Complex third-party handshakes that require robust state machines.
Compliance: Regulatory constraints like GDPR, HIPAA, or SOC2 that require strict data isolation or audit logging layers.

In these cases, complexity is insurance, not vanity.

4. The "Removal Test"

Every layer adds cost: velocity, cognitive load, and deployment complexity. Before adding a new abstraction, ask yourself:

"If we remove this layer tomorrow, how painful would it be?"

If removing it is harmless or just makes the code slightly "messier," it probably didn’t need to exist yet. If removing it would cause a cascading failure of logic or data integrity, the layer is doing its job.

5. The "Necessary Complexity" Checklist

You know you’re making the right move when:

Evidence-based: You’ve observed patterns that repeat in real user data.
Cognitive Clarity: Developers can reason through flows without fear.
Hard Constraints: The system has scaling, security, or regulatory requirements that force abstraction.
Intentionality: Every additional layer is intentional, not speculative.

Conclusion

The difference between premature and necessary complexity comes down to experience, evidence, and clarity. When your complexity solves actual problems, scales safely, and is understandable, it becomes an asset, not a liability.

This is part 2 of my series on Backend Architecture. If you missed it, check out part 1: The Hidden Cost of Over-Engineering Early-Stage Backend Systems.

The Hidden Cost of Over-Engineering Early-Stage Backend Systems

Ajinkya Ashokrao Pawar — Sat, 24 Jan 2026 19:47:19 +0000

I used to believe good backend engineering meant preparing for the future from day one.

Clean architecture.
Perfect boundaries.
Systems that could scale before they ever needed to.

It felt responsible. It felt professional. What I didn’t understand yet was this: early-stage systems rarely fail because of load. They fail because they become hard to change.

I learned this while working on a backend that looked excellent on paper. We had separate modules, clear interfaces, and well-defined responsibilities. Authentication lived in its own area. Messaging had its own flow. Even internal calls were abstracted behind contracts.

The architecture diagram was beautiful. The product, however, moved slowly.

The Hidden Cost: Velocity vs. Clarity

A small feature request like "add one field to the response" meant touching multiple layers, updating contracts, retesting unrelated flows, and redeploying more than one service.

Nothing was broken. Everything was heavy.

That’s the first hidden cost of over-engineering: velocity collapses before product clarity exists. At an early stage, your backend doesn’t yet know what it wants to be. You don’t know:

Which APIs will survive.
Which features are temporary.
Which flows users actually care about.

But over-engineered systems assume permanence too early.

The Evolution of Friction

Here’s a simple mental diagram many backend systems start with:

Client -> Controller -> Service -> Repository -> Database

It's readable. It's traceable. It's fast to reason about. Now compare it to what often appears too early:

Client -> API Gateway -> Controller -> Service Interface -> Implementation -> Adapter -> Domain Layer -> Event Publisher -> Consumer -> Database

Each layer makes sense individually. Together, they create distance between intent and behavior.

When something breaks: You don’t debug logic-you trace architecture.
When behavior changes: You modify abstractions instead of outcomes.

The system becomes technically correct but cognitively expensive.

Operational Complexity & The Human Factor

Another cost appears quietly: operational complexity without operational benefit. Multiple services mean more deployments, more configuration, more logs, and more failure points-long before traffic justifies them.

Early systems don’t need to survive millions of users. They need to survive daily change.

Over-engineering also affects people. When code becomes intimidating, developers hesitate:

Refactors get postponed.
Small improvements feel risky.
Momentum slows, not because the team lacks skill, but because the system resists movement.

This is the danger zone: Not broken enough to fix. Not simple enough to evolve.

What to Prioritize Instead

None of this means architecture is bad. It means architecture has a timing cost. Early-stage backend systems usually benefit more from:

Fewer moving parts.
Boring, obvious flows.
Easy local setup.
Fast debugging paths.

You can extract services later. You can add resilience later. But you can’t easily recover speed once it’s gone. Scaling late is painful, but possible. Stagnation is quiet-and often fatal.

Conclusion

The hardest backend skill isn’t designing for scale. It’s knowing when the system doesn’t deserve that complexity yet.

Check out Part 2: When Over-Engineering Actually Makes Sense (And How to Know You're There)