Introduction

For my most recent coding project, I was tasked with building a Java application that could handle thousands of CSV and JSON files, perform computations on the data, and present it in a user-friendly manner. This architectural approach, involving distinct components within an application, is known as N-Tier Architecture. In this article, I'll delve into what N-Tier Architecture entails and detail how I implemented it.

What is N-Tier Architecture? 🚗

Imagine this scenario: your car's check engine light illuminates. Your car's dashboard is smart enough to pinpoint the potential malfunctioning part. This is possible because a car comprises numerous smaller components. Consider if a car were made up of only one or two parts. Any issue with the vehicle could necessitate paying for a costly major part or even replacing the entire vehicle!

Similarly, in software development, the concept of multiple pieces contributing to a whole is crucial. Embracing modularity is essential—when software is modular, individual parts are less reliant on each other. Consequently, if a bug surfaces, addressing it might only involve reworking a specific section rather than the entire program. Swiftly rectifying bugs in an isolated manner is vital to uphold application uptime.

How I applied N-Tier Architecture? 🤓

Referring to The Solution Architect's Handbook by Saurabh Shrivastava & Neelanjali Srivastav, when assessing solution architecture design patterns, a commonly employed one is the "n-tier layered architecture." When scrutinizing any application, it can typically be deconstructed into three main components (though it can certainly involve more):

1. Web Layer

2. Application Layer

3. Database Layer

The web layer encompasses what the end user interacts with. Think about scrolling through your Facebook feed—the content is presented through user interface code.

The application layer, often referred to as the middleman, handles most computations to fulfill user requests. Taking the Facebook example, clicking on a profile involves the application layer interacting with the web layer to execute the action. The outcome—retrieving another user's profile—is then presented to the end user.

Lastly, the database layer is what is storing the data for the application layer to run actions on. Seems easy enough right?

The image below is what our application structure looked like

Here's how we did it:

1. We parsed around 450,000 individual data outputs from distinct CSV and JSON files. We established a data layer (referred to as datamanagement) to read and store the data in a Java data structure, essentially functioning as our "database."

2. Our application layer (labeled as processor) devised various methods to extract data from the initially created "database." The data comprised COVID-related records, including vaccination data per zip code, population data per zip code, and property data encompassing home market values and related fields. One of our methods, for instance, calculated the average market value for homes in a specific zip code

3. Our web layer (referred to as ui) presented users with an array of available data computations and exhibited the results in the terminal. Extending the prior example, if a user requested the average market value for the "19102" zip code, the output would read "315,000."

4. Additional layers like logger and util facilitated data exchange between the core layers.

Conclusion

Even though this application wasn't deployed to the web, I gained invaluable insights into software design principles and the art of crafting controlled dependencies between each layer—just enough to ensure their functionality (no pun intended 😉)