Deriving a DDD Application Architecture from a Three‑Layer Structure and Implementing It as a Maven Archetype

The article begins by stating that many DDD implementations (classic four‑layer, hexagonal, clean architecture, CQRS) share the same core ideas, and it will not cover each in detail but instead start from a simple three‑layer architecture to derive a custom DDD‑oriented application structure.

It first explains why the data model layer can be merged with the DAO layer because the model is a plain Java bean that directly maps to database tables and is tightly coupled with ORM annotations.

Next, the Service layer is refactored to extract business logic into a domain model. The original Service method is shown as a bulky transaction script, and the refactored version delegates all business rules to the domain object, leaving the Service to coordinate loading, invoking, and persisting the domain.

The domain model lifecycle is managed through a Repository interface, abstracting persistence details away from the domain layer. The Repository is placed in the infrastructure‑persistence package, while external calls are handled by an infrastructure‑gateway (anti‑corruption layer).

The UI layer (controllers) is renamed to ui‑web, and the Service layer becomes Application Service. A launcher module is introduced to host the application entry point, completing the Maven module structure.

All steps are illustrated with architecture diagrams (three‑layer, after step 3, after step 4, and final package layout).

After the architectural discussion, the article introduces the ddd‑archetype Maven archetype, which encapsulates the described structure. It provides a step‑by‑step guide to install the archetype using IDEA: cloning the project, running archetype:create‑from‑project, install, and archetype:crawl, and configuring the local Maven catalog.

Example Maven commands are shown, for instance: git clone https://github.com/feiniaojin/ddd-archetype.git and the Java service code before and after refactoring:

public class Service {
    @Transactional
    public void bizLogic(Param param) {
        checkParam(param);
        Data data = new Data();
        data.setId(param.getId());
        if (condition1 == true) {
            biz1 = biz1(param.getProperty1());
            data.setProperty1(biz1);
        } else {
            biz1 = biz11(param.getProperty1());
            data.setProperty1(biz1);
        }
        // ... other logic ...
        mapper.updateXXXById(data);
    }
}

public class Service {
    public void bizLogic(Param param) {
        checkParam(param);
        Domain domain = loadDomain(param);
        SomeValue someValue = this.getSomeValueFromOtherService(param.getProperty2());
        domain.doBusinessLogic(param.getProperty1(), someValue);
        saveDomain(domain);
    }
}

The article then presents a complete backend example (Spring Boot, H2, Spring Data JDBC) and a frontend example based on vue‑element‑admin, each with GitHub links and screenshots.

Finally, it summarizes that the refined architecture bridges classic four‑layer, hexagonal, and clean architectures, and encourages readers to further explore DDD concepts such as bounded contexts, aggregates, factories, and domain services.