Layered Pattern for Software Architecture

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We are continuing our season and really kicking off, although we did an overview, we're really kicking off our season now on patterns and anti-patterns for software architecture. This first episode, we're going to tackle the layered pattern. Sometimes this is known as in, as in the letter tier pattern, and it is a way to break up our application into multiple layers and thus take a big problem and break it into smaller ones. If you think of these smaller ones as some sort of a silo, it is sometimes easier to do that because you can within each silo, sort of have a context and hopefully minimize the interactions, the integrations between those silos, which allows you to sort of focus on one thing at a time, solve that and then have it essentially pass some data back and forth to the other pieces. Basically what you end up with is four layers and each of these can actually be split into what we'll call sub layers. So, you know, it's not necessarily four layers. There may only be three and there may be, I don't know, there could be 30. I don't know how complex you can get it, but you could easily double it up to, you know, eight or 10 layers, depending on how you want to do stuff. So we're going to start with the layer pattern defined and it is typically going to have four layers that I mentioned. It's going to be the presentation layer, also known as a user interface, the application layer, which is sometimes called the service layer, the business logic layer and the data access layer, sometimes known as the persistence layer. Now that last one in particular is a good example. As you have the data access layer and persistence, sometimes those are two separate layers by themselves. You may see, for example, a database, there's a database layer where your data is stored and you can retrieve it. But then on top of that is data access objects or a data access layer, which allows you through the data access layer to potentially point to different persistence tools and methods. You see this sometimes in commercial software where the data access layer is consistent for everything forward of the data access layer. But behind it, there is a way to configure things to maybe go to, for example, like a MySQL database or a Microsoft SQL database or an Oracle database or you name it or file system or something else. So you will see some of these layers actually get broken into other layers that make sense for them. The whole goal being one, really to take this big problem and break it into smaller problems that are easier to solve. We've seen this before where you take something big and just break it down, break it down until the complex is much easier to solve. And then you're solving smaller, simpler problems instead of big, huge, complex, almost maybe unmanageable problems. And you'll see in other layers, there's places, there's ways that we can split things up. We may have within the business logic layer, sometimes you have the business logic, the core thinking, the core brain of the application. You may have a layer on top of that that is, as I mentioned, a service or an API. You may have it in some way that there are layers essentially to that business logic. So there may be some sort of a front and a back to that and maybe even a middle where part of the business logic is more around display type of manipulation, but maybe somewhere closer to the back end is more data manipulation and in between maybe some sort of some business rules and things like that. Typically if you get to too many layers, it becomes really difficult to deal with. So you don't want to go crazy, but you can. And you can't even within a layer, you can have different silos to help you distribute that application across multiple resources, such as multiple servers, multiple web servers. If you're talking front ends, maybe you have an application server and a web server. So maybe you have something that just takes the basic HTML basically, essentially comes in, the HTML that gets generated out to the client. But maybe behind that, it's got some sort of a smart thing that's actually generating that HTML, we'll say essentially on the fly as it's being requested. So there's a lot of things that you can run into that would change around how these layers work. The goal though comes back to simplifying and not really batching, but grouping features. Front end is a great one is you have the front end stuff. So it's probably going to be written in maybe JavaScript and HTML. It's going to be focused on displaying data. If you're doing a lot of data manipulation other than just to display it, then you're probably not doing things right. And that's where the challenge is, is to within a layer, keep it effectively standalone so that it doesn't need other layers, that the interaction is well defined so that you have integration points. And that's the only place that you will see overlap. And that's not even overlap at that point. That's the only place where you will see communication from one layer to another. If you are storing stuff and doing some of the work that another layer should be doing, then that is, as well they say, problematic because what's going to end up happening is that you're going to have stuff that's maybe a duplication of effort, but also you're going to have stuff that's not well suited to do the work within that layer. Because remember, we've got this context within each silo. And if you're outside of that silo, then some of the benefits that you get from that context are no longer going to be there. A great example that people probably have run into in web development is you have sessions. You have the idea of a session within a web application. And once you move away from the web server, you don't have necessarily, actually you don't, you don't have that session data unless you explicitly pass it or move it. And so if you're finding yourself having to explicitly move data just to solve a problem in your particular layer, then maybe that problem should have been solved in another layer. And that actually brings us to one of the challenges that we often see within this pattern is figuring out what layer the work belongs in. Data, the backend, the data layer usually is pretty, the persistence layer makes sense. It's like, okay, this is where I'm storing my data. All the way up on the front end, where I'm displaying results or interacting with the user more or less makes sense. But even within those, sometimes stuff is moved around so that we're doing work that we shouldn't. In the front end in particular, actually both of those, what we'll find a lot is that we will make allowances, we'll call it. We will make allowances, we'll break the rules because it maybe is more efficient either in interactions or data moved or timing to do some sort of calculation within that layer. The front end is where we see this a lot, where maybe we send a whole bunch of data to the user initially. And then when they're doing things like, let's say sorting data, filtering data, maybe even doing some sort of calculations and manipulations of data, that we're doing all of that in the front end first. And then at some point, I will say there's like a save or something that causes that data then to get pushed back and persisted all the way back to the backend, which is doable. We can do that. And sometimes we need to because there's some sort of a timing, there's a lag. Maybe there's too much data that we're working with or too much work that we want to do. But honestly, we're better off really thinking about pushing that to the backend. A great example would be if I want to do, let's say at the front end, I've got hundreds or maybe even thousands of records. And one of the things I want to allow the user to do is to be able to do something across all of those records at once. Now you can do that in the front end and then pass all that data back. But often it is actually going to be more efficient and better to take that work, that large and you know, should be probably it's going to be a larger amount of work and push that to the backend because sometimes that doesn't even have to be real time. You know, we can just batch it in the backend. So the backend that probably has more resources and is better suited to do that job can do that job. One example that I've run into the past was just doing some file processing. I was sucking in data from files and having to do a lot of manipulation and then save it off to a database. It turned out that when I sucked the data into the database and did all of the work within the database, and a lot of it was bulk changes and things like that. When I sucked the file in and did the work within the database as opposed to doing the work outside of the database and then saving it, it was a order of magnitude, maybe multiple order of magnitude faster doing it within database. It was something that was, I want to say it was taking me 10 to 15 hours to run it and this is a large data set, but still taking 10 to 15 hours to run it the first way. And then when I flipped it over the database, it was under an hour and I want to say it was even under 10 minutes that you have this tool, the relational database was built to do that kind of work, exactly the work that I had it doing. So why not utilize that? And that's part of the goal of the layers, particularly in this one is do the work where it makes the most sense. For example, a lot of there's going to be libraries and features, particularly if you're dealing with some sort of a JavaScript like an angular react or something like that. There's a lot of stuff there, a lot of code that's been written to do presentation style manipulation, things like building selection lists and defaulting values and stuff like that. That's basically display related stuff. It doesn't make any sense to try to do those calculations in the back end and then push everything forward. It's a it's almost a just in time calculation of or function, whatever that function happens to be. But we need to think about that where certain layers are going to be in the tools available within that layer are going to be more effective. They're going to be better at doing X, whatever that function is that we're working on. Now, another thing is I sort of alluded to when you talk about the layered pattern is you have sort of a plug and play option that becomes available when you use a layered pattern. This is very useful when you have software that's going to live for a long period of time. A good example of this in recent years or decades was the move to mobile devices. Before, we often had a screen. You had a big computer screen. It was depending on what year you may have started at 800 by 600. It worked its way up to camera like 2000 by 1240 or whatever it was. You had all these different resolutions so you could put a lot of stuff on the screen. Your real estate was huge. And even within that, you sort of owned the display enough that you could define stuff in a way to say, all right, I'm working on a 800 by 600 place or 1024 by whatever it was, 1024 by 800 or whatever. I forget all those. But you can work within that real estate you had set area to work with in the modern world. You don't have that when you start looking about talking about responsive design on an interface. That whole thing is the responsive part is we don't know what we're looking at as far as screen real estate. It's going to move. It's going to change. And we need to still display in some way based on whatever the display is in a way that's useful to the user. If we tied everything into our presentation layer in the past and within that presentation layer had application functionality and business functionality and maybe even some data access functionality, then when we make the change, we have to carry all of that stuff over into the new implementation of our presentation layer. And now, assuming we support both, I said we have desktop and we have mobile and we've got logic for business logic and data access logic that's up in that UI layer. Now we've got to maintain it in two places because those things are probably not going to work together. So we want to be able to have that plug and play. If we cleanly have these silos, then we can swap to a different silo when we need to. I mentioned that earlier. It works great on the back end where you have a data access layer that you can swap out different databases and even within a database engine, different versions. So if there's a new Oracle, if they go from, I don't even know where the versions are, if they go from version nine to version 10 to version 11, you can have an access layer that actually supports all three database types. And it may not have to, all you have to do is maybe implement just the database in each of those and you're off and running. Now that may be, it may or may not be more or less complicated than the front end. If you put a lot of stuff into store procedures and triggers and things that live in the database, then you're going to have to replicate those across all of your engines. So the more you pull that out, the better it is or the more flexible it is. In a sense, more scalable it is as well, because that data access layer, you can put some sort of a, some sort of a routing tool or something like that, that, that gives you load balancing of some sort or data balancing of some sort. So your data access layer could be, it could be as simple as users that have a last name from A to M get one database. And those that have N to Z have another database, you know, or you can, there's all different ways you can slice and dice stuff, which is where you start getting into interior is that you can actually split this stuff up and you can keep those silos while the, the code is effectively the same, they will point to slightly different data sets or have different users utilize them. So you're able to actually start in a horizontal way, slicing and slicing up your application so that you can expand it horizontally instead of vertically. And that's really all we need to cover from a layered point of view. I don't want to get too much deeper into it. If you want to look at, if you want to go out and Google or whatever your favorite search engine is, layered pattern examples, you can probably see some good examples of it. I think that's, yeah, if you get too much deeper into it, you're probably gonna get into specifics for specific problem, specific solution. But with layered pattern, it's, it's pretty self-explanatory. You have layers, three, four players, and thinking from front end to back end, that UI, that business logic, some sort of application or service layer, like an API, and then a data access layer, maybe data access layer and a persistence engine. That being said, we can wrap this one up and next time we're just going to keep chugging along through different patterns. The challenge this time around, as always, don't go out there and have yourself a great day, a great week, and we will talk to you next time. Great success. There are two things I want to mention to help you get a little further along in your embracing of the content of Developineur. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developineur site. You can also find it on Amazon, search for Rob Rodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week and this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at Developineur.com if you would like more information. Now go out there and have yourself a great one.