Software Architecture Fundamentals - 04

-

 


🧠 Conway’s Law & Modern Software Architecture: A Simple Guide

👷 Who Was Mel Conway & What’s His Law?

Back in the late 1960s, Mel Conway made a pretty big observation that no one really paid much attention to at the time. But today? His idea is a cornerstone of modern software architecture and agile thinking.

👉 Conway's Law says:

“The structure of your software will reflect the communication structure of your organization.”

In simple terms, how your teams talk to each other determines how your code ends up looking.

🏢 Siloed Teams = Siloed Systems

Let’s say you’re at a traditional company:

  • One team handles databases,

  • Another builds the user interface (UI),

  • A third team writes business logic.

These groups often work in silos — each one doing their own thing with limited communication between them. What happens in code?

You get an N-Tier system:

  • 🧱 Database Layer

  • ⚙️ Business Logic Layer

  • 🖥️ UI Layer





And just like the teams, the layers don’t “talk” to each other easily. If you need a database change, you have to:

  1. Submit a formal request.

  2. Wait.

  3. Possibly...wait more.

⏳ Why Is This a Problem?

Because it's slow. The delays pile up, and even if you’re working fast in your own silo, the overall delivery grinds to a halt.

🚀 Enter Agile: Vertical Slices & Stories

Agile development turns this model on its head.

Agile teams focus on vertical slices — building small, user-focused features from top to bottom:

  • From the UI all the way to the database,

  • All handled by a cross-functional team with all necessary skills.

Each slice is driven by a user story — not a technical spec, but a real-world task the user wants to accomplish (like "generate an invoice" or "track inventory").

Agile demands fast iteration. That means:

  • No long waits for siloed teams,

  • Direct ownership of everything needed for a story.

🏗️ Changing the Code to Match Agile

Here’s the catch: You can't just go agile in process — your code has to change, too.

Old architectures (like N-Tier) don’t support this fast, flexible way of working. That’s why many modern teams move to microservices — small, independent units that map directly to agile teams.

Each microservice = one team’s domain
✅ Small
✅ Focused
✅ Independent

🧰 Why “Big Upfront Design” Doesn’t Work Anymore

In the past, teams would try to design everything at the start — the so-called Big Upfront Design (BUFD). The thinking was:

“Making changes later is expensive, so let’s design it all perfectly now.”

Spoiler: that rarely worked.

Requirements change. Users shift. The result? You ship something that’s “on time and on budget” but totally useless.

🧩 Agile’s Take: Evolve the Design

Agile teams don’t try to get it all right up front. Instead:

  • Build one small piece (one story),

  • Learn from it,

  • Update the design as needed.

The design grows with the system. You delay big decisions (like database or framework choices) until the last responsible moment — the point where not deciding becomes a problem.

🌍 Domain-Driven Design (DDD): Build What People Actually Use

This leads us into something called Domain-Driven Design (DDD).

Introduced by Eric Evans in 2004, DDD is about structuring your code around the actual work your users do — not around tech layers.

If you’re building an accounting app, your code should have:

  • Ledger

  • Balance Sheet

  • Credits/Debits
    …not just "tables" and "controllers."

DDD aligns the software with the business domain, not the tech stack. This makes the system easier to understand, modify, and evolve.



🧱 From Tiers to Bounded Contexts

DDD brings in the idea of bounded contexts — think of them as logical boundaries around parts of your business.

For an eCommerce app:

  • Store context (sales, promotions)

  • Warehouse context (inventory, shipping)

Each context has:

  • Its own team

  • Its own language

  • Its own models

This avoids messy, one-size-fits-all objects. For example, a "product" in the store means "book with a title," while in the warehouse it might mean "box with a barcode."

Treat them as different things, even if they share the same name.

🕹️ Microservices = Bounded Contexts in Code

In implementation:

  • Each bounded context becomes a module, subsystem, or a microservice.

  • These components communicate via well-defined interfaces (we call them portals or APIs).

📦 Monolith vs Microservices

  • In a monolith, all code lives in one big app, usually sharing one big database.

  • In microservices, each service is small, independent, and may even use a different database or language.

Each choice has pros and cons, and your architecture should reflect your team and problem, not trends.

🧪 Tech Choices & the Role of the Architect

Once you’ve structured your system around bounded contexts, it’s time to choose:

  • Database? SQL, NoSQL, files?

  • Communication? JSON, messaging queues?

  • Hosting? AWS, Azure, or something open-source?

An architect’s job isn’t to know everything but to ask the right questions, research, and collaborate.

❌ Don’t Pretend to Know Everything

It’s okay to say, “I don’t know — let me research.”

🛠️ Avoid Vendor Lock-In

Vendor tools (like AWS services) are tempting, but they often lock you in. Open-source tools give you freedom and flexibility in the long run.

🧭 Final Thoughts

Here’s the big takeaway:

✅ Your code architecture should reflect your organization and your users’ needs.
❌ You can’t be agile if your code is still stuck in a waterfall-era structure.

Architecture isn’t just about technology. It’s about modeling the people and problems your software is meant to serve.

🔜 Coming Up Next:

In the next post, I’ll dive into the design process itself:

  • How to start small

  • Design on the go

  • Keep systems coherent without upfront overload

Comments

Post a Comment

Popular posts from this blog

Apache Kafka - The basics

-
Image
 What is Kafka? Event and Message streaming platform Yes, It is open-source and freely available. There are some commercial availabilities also.  Producers( AKA publishers) push messages/events to Kafka Consumers( AKA subscribers) listen & receive messages/events Publisher ?? Subscriber ??  Don't worry. Let's take a look at it before digging deep. 😊 Publisher Subscriber Pattern. Consider below case. A sender sends message to the receiver.  Sender needs to know the receiver address ( means receiver address should configure in Sender side) Both parties should agreed upon common protocol/format for data sending and receiving.  Now see this case,  Now 3 receiver addresses should configure in sender side.  And if you need to add a new one, then sender side also has a change to be done.  Imagine multiple sender sending multiple receivers ,  Yes. the configuration is a mess now. It is not easy to add a new receiver because there can be many sen...
Read more

Kafka: How to handle duplicate messages

-
Image
Kafka is "at least once" by default. ???? What is "At Least Once" in Kafka? (Simple Explanation) "At least once" means: Kafka guarantees that every message will be delivered , But sometimes the same message might be delivered more than once (duplicate). 🔁 Why it happens: If a consumer crashes or times out, Kafka resends the message after retry.            (Here, what I meant by resend  that Kafka allows to pull the same message. If you know about Kafka Architecture it does not push/ send messages to consumer. Instead consumer is the one pulls the messages) If the system didn’t record that it already processed it, it may process it again . 🛠 Example: You (Consumer) receive a payment event. You process it and update the database. But before you commit (Telling Kafka "I have successfully processed this message" or in other words consumer failed to submit the offset to Kafka ), the consumer crashes. Kafka thinks it fa...
Read more

Spring: How to deal with circular dependencies

-
Image
  🔄 Solving Circular Dependencies in Spring Boot: A Complete Guide When your Spring services get tangled up and can't start - here's how to fix it! 🤔 What is a Circular Dependency? A circular dependency happens when two or more Spring beans depend on each other, creating a loop. Spring can't figure out which bean to create first, so your application fails to start. Think of it like this: Service A needs Service B, but Service B also needs Service A - it's like two people waiting for each other to go first through a door! 🚪 💥 How Does It Happen? (Real Example) Let's say you're building an e-commerce app: @Service public class OrderService { @Autowired private PaymentService paymentService; public void createOrder(Order order) { // Process order paymentService.processPayment(order.getPaymentInfo()); } } @Service public class PaymentService { @Autowired private OrderService orderService; // ...
Read more