Layered Architecture: Strict, Relaxed, and Inheritance‑Based Approaches

In application development, a strict single‑layered architecture is theoretically possible, but in practice multiple architectural patterns are mixed, which can lead to confusion if the layers are not clearly defined.

Strict Layered Architecture follows the OSI‑style model where each layer depends only on the layer below it, enforcing one‑way coupling and communication. The principle of one‑way dependency is emphasized to avoid circular references.

Relaxed Layered Architecture (Relaxed Layered System) is used in Domain‑Driven Design (DDD). Layers may use services from any lower layer, not just the immediate one, and some services can be visible to multiple upper layers, though the one‑way dependency rule still applies.

Inheritance‑Based Layering also appears in DDD, where higher layers inherit and implement interfaces from lower layers, requiring the infrastructure layer to be moved to the top of the hierarchy. The same one‑way dependency rule holds, meaning domain, application, and presentation layers cannot depend on the infrastructure layer, but the infrastructure layer may depend on them.

Example Java code shows a domain‑level UserRepository interface and its infrastructure implementation JpaUserRepository :

package com.mallfoundry.user.domain;

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

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);
    }
}

The article also notes that package naming does not guarantee proper layering, and the placement of repository implementations depends on whether a relaxed or inheritance‑based layering approach is used.

It then outlines the historical evolution of layered architectures:

Stage 1: Two‑layer system (presentation and database) where the view directly uses ResultSet .

Stage 2: Three‑layer system (presentation, domain, database) with object‑oriented representations replacing direct ResultSet usage.

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

Further stages discuss object‑oriented design’s impact on the domain layer and the effect of front‑end/back‑end separation, where the presentation layer is fully decoupled and the back‑end provides APIs (RESTful, gRPC, GraphQL). Two development routes emerge: Backend‑for‑Frontend (BFF) and aggregation‑based interfaces.

Overall, the article encourages a disciplined, one‑way dependency approach to layering while adapting to modern architectural trends such as DDD and front‑end separation.