Search code examples
encapsulationdistributed-computing

Encapsulation of layers in a three-tier software architecture for client-server

The three-tier software architecture for client-server paradigm has three different layers:

  1. Presentation layer - A layer that users can access directly, such as UI or Webpage. Also called a client.

  2. Application layer - This layer encapsulates the business logic (such as business rules and data validation), domain concept, data access logic and etc. Also called middle layer.

  3. Data layer - The external data source to store the application data, such as a database server.

Why is it advantageous to encapsulate the logic of separate layers in separate software modules?

Solution

  • There are a couple of reasons you should encapsulate the logic of separate layers in separate software modules.

    1. It forces you to practice Separation of Concerns/SRP.

    This horse has been beaten to death, so I will reference other StackOverflow questions. If you truly keep different concerns in different files/modules without too much coupling, you will be a happier developer. You haven't seen hell until you've seen a 30,000 line "God Class" that does everything, and is impossible to add or remove features from, fix bugs in, or refactor.

    2. It helps you break up your code into manageable chunks.

    Coders have been breaking up code into different modules for some time now because it helps us understand the bigger picture. You typically need the structures and adjectives that modules give you once your system gets beyond a small size, or you need to work with other developers.

    3. It can help you distribute your code onto different machines/architectures in the future.

    Putting your software into different modules can make it easier to distribute them onto different machines (i.e. distributed computing) in the future. If your modules don't have shared state and aren't overly-coupled, you can move the modules to different machines. It won't do this automatically though, you will still have to deal with the interfaces (rpc/services/etc) and all the fun of distributed computing.

    Note: You can easily sidestep all these benefits if you over-couple your modules. Typically you want your minimal module coupling to follow the direction that your data flows (i.e. the presentation layer shouldn't talk to the database).