repository·master·Indexed 19 days ago
https://github.com/bancolombia/scaffold-clean-architectureA Gradle plugin that automates the scaffolding of Java applications based on Clean Architecture principles and Bancolombia's specific best practices. It organizes projects into four layers: Domain (business logic), Usecases (application logic), Infrastructure (Entry Points, Driven Adapters, and Helpers), and Application (module assembly and dependency injection via @ComponentScan).
@ComponentScan annotation to automatically discover and register Use Case beans, injecting the necessary concrete instances of their declared dependencies (from the Infrastructure layer) at runtime.The validateStructure task enforces the Dependency Rule: source code dependencies can only point inwards. Inner circles must not know about anything in outer circles. The task enforces the following specific constraints:
AppService module.The example-mongo project follows a Clean Architecture pattern organized into specific layers. The flow moves from external components (Infrastructure/Entry Points) towards the core business logic (Domain/Usecases), with the Application module acting as the orchestrator.
Domain entities. It reacts to invocations from Entry Points.public static void main method).This project implements Clean Architecture by separating concerns into distinct layers. The architecture flows from the outermost layer (Application) to the innermost layer (Domain).
@ComponentScan. This is the only module containing the public static void main(String[] args) method.The project follows a layered Clean Architecture pattern, organized from the most external components to the core business logic. The layers are:
public static void main method). It uses @ComponentScan to automatically register UseCase beans.The Scaffold Clean Architecture Gradle Plugin generates a multi-module project following Robert C. Martin's Clean Architecture principles. The architecture is organized into three main layers where dependencies always point inwards:
Domain (Internal): Encapsulates business rules and logic.
model module: Contains domain models, entities, and defines ports (interfaces).usecase module: Contains application logic and orchestrates flows using the ports defined in the model module.Infrastructure (Middle): Contains technical implementations of the domain ports.
entry-points modules: The start of business flows (e.g., REST controllers, Kafka consumers).driven-adapters modules: External implementations (e.g., database connections, REST/SOAP clients, file readers).helpers modules: General utilities for Driven Adapters and Entry Points.Application (External): The outermost layer responsible for assembling modules, resolving dependencies, and creating beans. This is the only module containing the public static void main(String[] args) method to start the application.
The project follows a Clean Architecture pattern organized into specific layers to isolate business logic from external details. The layers are organized from the most internal (core business) to the most external (infrastructure and application assembly):
public static void main(String[] args) method.Application module is configured with a @ComponentScan annotation. This allows the framework to automatically discover and instantiate UseCase beans and inject their required dependencies (such as Driven Adapters) during the application startup.To avoid concurrency issues caused by shared mutable state, ArchUnit enforces that all dependencies in UseCase classes and Spring @Component (Beans) must be immutable.
final.@Value on fields. This ensures all dependencies are final and immutable.// Compliant Bean using constructor injection
@Component
public class MyService {
private final String endpoint;
public MyService(@Value("${external-service.endpoint}") String endpoint) {
this.endpoint = endpoint;
}
}Driven Adapters and Helpers are part of the Infrastructure layer.
Note: Helper classes cannot exist in isolation; they must be inherited/used within Driven Adapters.
Modules are generated using Mustache templates. The following variables are available to impact template generation:
Boolean Variables:
lombok: Enables/disables Lombok annotations (default: true).metrics: Enables/disables metric generation (default: true).reactive: Determines if the module is reactive. If true, the resource directory follows the <module-name>-reactive pattern; otherwise, it uses <module-name> (default: false).Predefined Variables:
projectName: The name assigned by the user.projectNameLower: The project name in lowercase.package: The user-defined package (e.g., co.com.bancolombia.sample).packagePath: The package path (e.g., co/com/bancolombia/sample).Constants class is available by its name (e.g., PLUGIN_VERSION).