I know 😆 it has been a long Time.
Today i will try to give you the knowledge i have gain by reading The Chapter 1 of this Amazing Book

The Evolution of layers

Firstly in the past something came and it was called client-server , and with the needs at the time it was pretty good , the web was not at the state it was today . But there was a problem and here i quote M. Fowler

If the application was all about the display and simple update of relational data, then these client–server systems worked very well. The problem came with domain logic: business rules, validations, calculations, and the like. Usually people would write these on the client, but this was awkward and usually done by embedding the logic directly into the UI screens. As the domain logic got more complex, this code became very difficult to work with. Furthermore, embedding logic in screens made it easy to duplicate code, which meant that simple changes resulted in hunting down similar code in many screens.

And here Object Oriented Community was coming with an idea 💡 , Create a Layer for The Domain although your layers do not have to be physical , they can live on two physical machines , but your project is composed of Three Layers

When people discuss layering, there’s often some confusion over the terms layer and tier. Often the two are used as synonyms, but most people see tier as implying a physical separation. Client–server systems are often described as two-tier systems, and the separation is physical: The client is a desktop and the server is a server. I use layer to stress that you don’t have to run the layers on
different machines. A distinct layer of domain logic often runs on either a desktop or the database server. In this situation you have two nodes but three distinct layers. With a local database I can run all three layers on a single laptop, but there will still be three distinct layers.

The Three Principal Layers

I think once in our life we have seen these layers 😆

1. Presentation: but these days it’s more likely to be a rich-client graphics UI or an HTML-based browser UI. The primary responsibilities of the presentation layer are to display information to the user and to interpret commands from the user into actions upon the domain and data source

2. Domain Logic : also referred to as business logic.
   This is the work that this application needs to do for the domain you’re working with. It involves calculations based on inputs and stored data, validation of any data that comes in from the presentation, and figuring out exactly what data source logic to dispatch, depending on commands received from the presentation.

3. Data Source : is about communicating with other systems that carry out tasks on behalf of the application. These can be transaction monitors, other applications, messaging systems, and so forth. For most enterprise applications
   the biggest piece of data source logic is a database that is primarily responsible for storing persistent data.

More about Layers

Presentation and Data Source are both interfaces what is the difference ? 😶

Presentation is an external interface for a service your system offers to someone else, whether it be a complex human or a simple remote program. Data source is the interface to things that are providing a service to you.

How To Separate Well These Layers ? 😶

Together with the separation, there’s also a steady rule about dependencies: The domain and data source should never be dependent on the presentation. That is, there should be no subroutine call from the domain or data source code into the presentation code. This rule makes it easier to substitute different presentations on the same foundation and makes it easier to modify the presentation without serious ramifications deeper down

Where To Run Yours Layers

The first advice is to run everything on the server , however , there is a couple of options for each layer

1. for the Data Source layer , i think we can all agree that it is so often on the server .

2. For the Presentation layer if it is a Rich UI ( build for example with javaFX ) it can live on the client , but if the presentation is a we based , it can live on a server ( Web Server to be explicit )

3. About the Domain logic layer i will finish by quoting M. Fowler

   This leaves us with the domain logic. You can run business logic all on the server or all on the client, or you can split it. Again, all on the server is the best choice for ease of maintenance. The demand to move it to the client is for either responsiveness or disconnected use. If you have to run some logic on the client, you can consider running all of it there—at least that way it’s all in one place. Usually this goes hand in hand with a rich client—running a Web server on a client machine isn’t going to help responsiveness much, although it can be a way to deal with disconnected operation. plitting across both the desktop and the server sounds like the worst of
   both worlds because you don’t know where any piece of logic may be. The main reason to do it is that you have only a small amount of domain logic that needs to run on the client. The trick then is to isolate this piece of logic in a
   self-contained module that isn’t dependent on any other part of the system. That way you can run that module on the client or the server. This will require a good bit of annoying jiggery-pokery, but it’s a good way of doing the job.

It is Up To You To Choose , depending on the complexity of the project you are working on 😎

I really , really quote the book because , it so well explained , i really enjoyed 😍.
Good Bye 👋