On the previous entry i was about to talk on N-tiered architecture. Let’s dive on what this software design brings to the table.
Essentially, we are separating a single piece of software into smaller ones that perform very specific functions depending on the layers of abstraction that we define. For example, we could break a single project into a data tier to perform the management and persistence of objects, a logical tier to apply different business rules, and a presentation tier to render this information into pages, forms and reports.
Let’s take this concept to a practical exercise. Consider a starting point similar to the one in the following diagram.
It is usually way more complicated, but drawing more lines will hardly make the problem easier to understand. Essentially, we have two applications that talk to each other, and both read and write from a database… But one of the databases is shared. Whenever Team1, that works on App1 and Database 1 make changes to Database 2, Team 2 must update App2 as well. So a lot of “alignment meetings” are created to keep the changes matched.
Now let’s see what a possible n-tiered solution to this problem could look like.
On a layered architecture, instead of the convoluted connection system of having multiple information links, there is an obvious point to receive information and a different one to put information. As well, we have included a data layer that interacts between the persistence and the business level, creating a level of abstraction that reduces complexity. We have also separated all elements located on Database 2 that App1 used, and created a new database for it, along with it’s own Data Tier application (though moving those components to Database 1 and it’s Data Tier could also be an option).
We could even have a common bus communication service that each component connects to, listens to events, and then reacts if the event triggered is relevant to the application, or discards it otherwise.
Now, it is true that there are more elements, and the apparent complexity has increased. Instead of maintaining two applications, two databases and a front-end website, we have nine different elements!
Bear in mind that the cross impacts that we used to have on the first scenario no longer happen. The first team’s modifications do not disrupt the workflow of the second team. This will also make all test scenarios easier, and open the door to create automatic testing for each separated component. And those three separated and untangled databases open a new door: database versioning. We will take a look at that on our next entry.