miw-upm/apaw-practice

1. This repository is a Spring Boot, Java, Maven application built as a layered teaching example. It is not a single business app; it contains many independent sample domains under one codebase, all following the same architecture.

2. The core architectural rule is one-way dependency flow: HTTP resources call domain services; domain services depend on domain persistence ports and domain models; MongoDB adapters implement those ports and map to storage entities. The domain layer stays separated from infrastructure concerns.

3. The API boundary lives in adapters/resources. Each business area has its own REST resource set, such as airport, bank, clinic, clothing store, football, music, recipes, recruiting, shop, sports academy, student council, university, vehicle, video website, videogame, warehouse, and winery. SystemResource provides a general system endpoint, and ApiExceptionHandler centralizes API error translation.

4. The business boundary lives in domain/services and domain/models. Every sample domain has its own service class set and its own model package, so each vertical slice is isolated rather than sharing a large generic model. Domain packages also contain enums, DTOs, and update/search helper objects when the use case needs them.

5. Persistence is abstracted through domain/persistenceports. These interfaces define what the domain needs from storage without binding it to MongoDB. This makes the domain layer portable and testable, and it explains the strong separation between “port” interfaces and concrete persistence implementations.

6. The MongoDB adapter layer is in adapters/mongodb. Each domain has its own subpackage with:

- Spring Data repositories in daos

- storage documents in entities

- MongoDB-based persistence adapters in persistence

- seeders to preload demo data

This layer is the concrete bridge between domain objects and MongoDB collections.

7. The data flow for a typical request is: REST resource receives the HTTP call, service applies business rules, service invokes a persistence port, the MongoDB adapter uses a repository to read/write entity documents, and the result is mapped back into a domain model and then into the API response. The same pattern repeats across all sample domains.

8. Seed data is part of the architecture, not an afterthought. Each domain has a dedicated seeder, and there is also a global DatabaseSeeder. This indicates the application is meant to run with reproducible demo datasets, especially in local and test environments.

9. The repo includes an outbound integration boundary in domain/restclients and adapters/restclients. UserRestClient/UserRestClientImpl represent calls to an external user service, so the application is not purely self-contained; at least one use case depends on another HTTP service.

10. Configuration and cross-cutting concerns are centralized in config. SecurityConfiguration, LoggingFilter, and RestTestConfiguration affect all modules, so they sit outside the domain slices and enforce application-wide behavior.

11. Testing is organized by architectural layer. There are service tests and service integration tests under domain/services, repository and persistence integration tests under adapters/mongodb, and functional tests for REST resources under functionaltests. That structure mirrors the runtime flow and validates each boundary separately.

12. The repository is built for containerized local execution and CI. Dockerfile, docker-compose.yml, and docker-compose-db.yml indicate a Docker-based runtime with MongoDB. GitHub Actions runs continuous integration, and SonarCloud is used for code quality gates, which are part of the project’s delivery pipeline.