SoftONELogic Alliance Network

Layering in software architecture

Creating programs that can handle very complex tasks calls for separation of concerns, allowing concentration on different parts of the design in isolation. At the same time, the intricate interactions within the system must be maintained in spite of the separation.

One of the function of layering in the software architecture is to make the relationship between layers to become as loose coupling as possible. In the three layer architecture, the user interface will be handled by Presentation Layer. Presentation layer responsible for the display of required form element and data from database. All business logic will be handled by Business Logic Layer. Accessing database will be handled by Data Access Layer. The usage of interface will make the relationship of each layer loose coupling.

Problem in 3 layer architecture

Even though there are separator between layers, there are still some problem need to take care in the 3 layer based development. If we talk about business logic, it should be handled by business logic layer. But in practical, sometime the business logic will lies in the data access layer through the usage of stored procedure.The question is, who control the design of the software?

Layering in DDD

The value of layers is that each specializes in a particular aspect of a computer program. This specialization allows more cohesive designs of each aspect, and it makes these designs much easier to interpret.

User Interface (or presentation layer)

Responsible for showing information to the user and interpreting the user’s commands. The external actor might sometimes be another computer system rather than a human user.

Application Layer

Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems.

This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.
 

Domain Layer

Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

Infrastructure Layer

Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on. The infrastructure layer may also support the pattern of interactions between the four layers through an architectural framework.