Understanding Layered Architecture: Strict, Relaxed, and Inheritance Approaches

In application development, a strict, single‑direction layered architecture is possible, but in practice many mixed architectural patterns are used, which can lead to confusion when different paradigms are combined.

Strict Layered Architecture is often illustrated with conceptual definitions or the OSI seven‑layer model. Layers help divide an application into groups of sub‑tasks, each residing at a specific abstraction level. Adjacent layers must have unidirectional coupling and unidirectional communication : the upper layer may depend on and call the lower layer, but never the reverse. The book POSA, Vol.I provides detailed specifications.

Relaxed Layered Architecture (Relaxed Layered System) is used in Domain‑Driven Design (DDD). The relationships between layers are less strict: each layer may use services from any lower layer, not only the immediate one. Some services may be visible only to the layer directly above, while others are visible to all higher layers. The architecture still respects unidirectional dependency (upper layers call lower layers only).

Inheritance Layered Architecture (Layering Through Inheritance) also appears in DDD. Higher layers inherit and implement interfaces defined in lower layers, and the infrastructure layer is moved to the top. The same unidirectional dependency rule applies: lower layers may depend on higher ones, but not vice‑versa.

Example code for the domain layer UserRepository interface:

package com.mallfoundry.user.domain;

public interface UserRepository {
    User save(User user);
}

Implementation in the infrastructure layer ( JpaUserRepository ):

package com.mallfoundry.user.infrastructure.persistence;

public class JpaUserRepository implements UserRepository {
    private final EntityManager entityManager;

    public JpaUserRepository(EntityManager entityManager) {
        this.entityManager = entityManager;
    }

    @Override
    public User save(User user) {
        return this.entityManager.merge(user);
    }
}

Packages alone do not truly represent layers; the placement of repository implementations depends on the chosen layering style. In a relaxed layered architecture they belong to the domain layer, while in an inheritance‑based approach they reside in the infrastructure layer.

The article also reviews the historical evolution of layered systems:

Stage 1: Two‑layer system (presentation + database), with direct ResultSet usage in the view.

Stage 2: Three‑layer system (presentation, domain, database), introducing model objects instead of raw ResultSet .

Stage 3: Four‑layer system (presentation, application/business logic, domain, database), separating business logic from the view and adopting MVC in the presentation layer.

Stage 4: Object‑oriented development, emphasizing domain models composed of attributes and operations; the application layer coordinates these models.

Stage 5: Post front‑back separation, where the presentation layer is completely detached and the backend provides APIs (RESTful, gRPC, GraphQL). Two development routes emerge: Backend‑for‑Frontend (BFF) and aggregation‑oriented interfaces.

These stages illustrate how layered architecture adapts to modern development practices, especially in the context of front‑end/back‑end separation.