Welcome to the Dee dive. Today we're really getting into
a core concept in software, something fundamental to well,
retty much everything digital. And here's the thing, it's
crucial because architectural decisions in software, they are
incredibly hard to change later on.
Really hard. And the the negative effects,
they can sort of bubble under the surface for years, maybe
even decades, before you really see the problem.
Absolutely. It's like setting the foundation
of a building, isn't it? Exactly.
Take Linus Torvalds, right, the creator of Linux.
After something like 15 years, he he famously called the Linux
Colonel huge and bloated, right? And that comment, it just
perfectly highlights how these early architectural choices,
they have such long lasting consequences.
They really do. So our mission today, our focus,
is to unpack one key idea designed to handle this
complexity, to let software systems actually evolve
gracefully. We're talking about layered
architecture. We're going to dig into the
principles, the benefits, which are often bigger than you might
think, and you know how it actually gets used out there.
And that's so important, understanding these concepts.
It's not just about definitions, it's about grasping why they
exist. They're essentially smart ways
to deal with just the sheer amount of information and
complexity you face when designing big systems.
OK. Great point.
SO with that in mind, let's start peeling back the layers.
Yeah, I said define what layered architecture actually is.
Yeah, nice. One it's.
Definitely not new. Yeah, it's one of the most
common patterns out there, and it's history goes way back.
We're talking the 1960s, seventies, the era of the first
really large software system. Right, it's foundational.
At its core, it's basically a method for organizing your code,
your classes, into these distinct groups.
These modules we call layers. Think of it like a cake.
Maybe you've got these layers. Stack one on on top of the
other, hierarchically arranged. A good analogy, but.
Here's the crucial part. Unlike Cake, there's a very
strict rule. A really strict 1A layer can
only use services. So calling methods, creating
objects, extending classes, declaring parameters, even
throwing exceptions only from the layer immediately below it.
That's the key constraint. Yeah, no skipping.
You can't reach down to levels. It's strictly one way direct
communication layer to layer downwards.
This discipline is what stops everything becoming a tangled
mess. And it sounds simple, but that
rule is incredibly powerful. It's how you partition the
enormous complexity of building a whole system.
You break it into these smaller, more focused components and this
layering it imposes discipline on how these components depend
on each other, which in turn makes the system much easier to
understand, much easier to maintain, and critically, easier
to evolve over time. That's huge for long term
projects. Can you give an example of that
benefit? Sure.
Let's say you need to swap out how your system communicates
over the network. Maybe you want to switch from
TCP to UDP. OK, because of the layering, you
can potentially make that change within its specific layer
without, you know, having to rewrite large parts of the
layers above it. The interface stays the same,
but the implementation behind it changes.
I see. So it isolates the change.
Exactly, and it also really helps with reuse.
Think about application protocols like HTCP for the web,
SMTP for e-mail, DHTP for network configuration.
They can all use the same transport layer underneath like
TCP. They don't each need to reinvent
how to reliably send data packets.
Right, that saves a ton of effort.
A massive efficiency gain, faster development, more
reliable systems because you're reusing proven components.
That's a perfect segue, actually, because network
protocols are probably the most common everyday example of
layered architecture we all interact with.
Definitely. Like when you browse a website,
your browser's using HTTP, right?
The hypertext transfer protocol that's sitting at the
application layer. But HTTP doesn't just magically
send data, it works with the layers below it.
It relies on PCP, the transmission control protocol,
the transport layer, and then TCP.
It hands things off to I the Internet Protocol at the network
layer. Getting closer to the wire.
Exactly. And then I uses something like
Ethernet at the communication layer to actually push the bits
over the physical network, the cable or Wi-Fi.
It's this really elegant stack. It is, and connecting this back
historically, one of the most influential early examples was
from Edgar Dykstra, a real pioneer.
Dykstra, 1968. That's the one.
He was designing an operating system called the HETHE and he
explicitly proposed using layers.
His system had, let's see, layer 0 for multi programming, kind of
the course scheduler. Then layer one handled memory
allocation, layer 2 was for inter process communication,
layer 3 managed IO input output and then layer 4 at the top was
where the user programs ran. Wow, quite defined even back
then. Very.
And Dijkstra's conclusion from building the AP was absolutely
critical. He found that the benefits of
structuring things this way hierarchically become more
important increasingly title as the project gets bigger and more
complex, which. Brings us right back to our
starting point about managing complexity in large systems.
Precisely. It underscores why these
architectural patterns aren't just academic exercises.
They're practical necessities for building robust software.
OK, so let's shift gears slightly.
We've talked principles, history, networking examples.
Now let's look at a really common specific layered pattern,
especially in business applications, the three tier
architecture. Yes, very common in enterprise
systems. Yeah, you see it everywhere.
But it wasn't always like this. If you go back before, say, the
late 1980s, most enterprise applications, think payroll
systems, inventory management, they were monolithic.
Right, big single chunks of code.
Exactly. Running on mainframes and users
connected through dumb terminals, basically just
screens and keyboards with no real processing power
themselves. But then networks got faster,
hardware got cheaper and more powerful, and it became
practical to actually split these applications up,
distribute them across different machines.
And that's where 3 Tier really took off.
It offered a more flexible way to build these distributed
systems. So let's breakdown those 3
tiers. What are they?
OK, so tier one at the top is the user interface, sometimes
called the presentation layer. What the user sees and
interacts. With exactly.
It's responsible for showing data to the user, getting their
input, handling things like button clicks, form submissions.
So if we think about an academic system, again, an instructor
entering grades, that form they use with the student names, the
grade fields, that's all part of the user interface layer.
Got it. Tier one dot UI What's next?
Tier 2 is the Business Logic layer.
You might also hear it called the Application layer.
This is really the engine of the system or the.
Rules live. Precisely, it implements the
system score business rules and processes.
So back to the grading example. This layer would handle things
like checking if the grade entered is valid.
Is it between zero and the maximum possible score for that
exam? Makes sense.
Or another rule might be after grade is successfully saved,
automatically send an e-mail notification to the student.
All that logic resides here in the business logic layer.
OK, UI business logic. What's the third tier?
The third tier at the bottom is the database layer.
Its job is pretty straightforward, store and
manage the data. Persistence.
Right, so after the instructor enters the grades and the
business logic layer validates them, this layer is responsible
for actually saving those grades permanently into the database.
And a key thing here is that this is usually a distributed
setup, right? These aren't all running on one
machine. Crucial point.
In a typical 3 tier setup, the user interface runs on the
client machine, your laptop, your phone.
The business logic runs on a separate application server,
often a pretty powerful machine or cluster of machines, and the
database that runs on its own dedicated database server, or
maybe a cluster of database servers optimized specifically
for handling data storage and retrieval efficiently and
securely. So.
Physically separate components communicating over a network.
Exactly. And within that middle tier, the
business logic, you often find further organization.
You might see, for example, something called a facade.
Yeah, it's a design pattern. It basically provides A simpler
unified entry point to a potentially complex set of
underlying business operations. Makes it easier for the UI
layer, the client, to talk to the business logic without
needing to know all the intricate details.
That's sort of. Like a simplified menu for the
complex kitchen behind it. Do an analogy and you'd also
typically find a persistence module in there.
It's job is specifically to handle all the communication
with the database layer. Talking SQL, handling
connections, that sort of thing. So it isolates the database
details from the core business rules.
Exactly. Keeps concerns separate.
The business rules shouldn't need to know how data is saved,
just that it gets saved. Makes sense for maintainability.
Now you mentioned 3 tier. Is there such a thing as 2 tier?
Oh yeah, definitely 2 tier architectures exist too.
In that model, you basically combine the user interface and
the business logic into a single layer.
OK, so UI and rules run together.
Right, typically they run together on the client machine
and then the database is the second separate tier, usually on
a server. What's the downside there?
Seems simpler. It can be simpler initially, but
the big disadvantage is that all the processing work displaying
the interface and executing the business rules happens on the
client machine. AH.
So the user's computer needs to be more powerful.
Exactly. It puts a much heavier
computational load on the client machines, which might not always
be desirable or feasible, especially if you have many
users or less powerful client devices. 3 tier distributes that
load more effectively. Right, that makes a lot of
sense. Well, as we wrap up this deep
dive, it's really clear that layered architectures aren't
just some theoretical thing, they're they're fundamental to
building software that can actually scale and last.
Absolutely. Understanding these patterns
like layered and three tier, it really gives you a blueprint.
It helps you understand how complex software is put together
and why it's designed that way. It's valuable knowledge for
anyone working with or even just using modern software systems.
Thanks for joining us for this look into layered architectures.
Thanks for having me.