Integrating the dddplus-maven-plugin Enforce Goal into Your Build Pipeline

The dddplus-maven-plugin enforce goal validates DDD-plus architecture compliance by executing three core enforcers—DDDPlusEnforcer, ExtensionMethodSignatureEnforcer, and AllowedAccessorsEnforcer—during the Maven verify phase to prevent non-compliant code from reaching production.

The dddplus-maven-plugin in the funkygao/cp-ddd-framework repository provides an automated mechanism to enforce DDD-plus architectural rules directly within your Maven build lifecycle. By integrating the enforce goal into your continuous integration pipeline, you can automatically validate domain model integrity, extension method signatures, and accessor usage before deployment artifacts are created.

What the dddplus-maven-plugin Enforce Goal Validates

The enforce goal is implemented in dddplus-maven-plugin/src/main/java/io/github/dddplus/maven/EnforcerMojo.java. When executed, it instantiates and runs three distinct enforcers in sequence:

new DDDPlusEnforcer()
        .scanPackages(rootPackage)
        .enforce();                              // DDDplus rule check

new ExtensionMethodSignatureEnforcer()
        .scan(dirs)
        .enforce();                              // Extension method signature check

new AllowedAccessorsEnforcer()
        .scan(dirs)
        .enforce(null);                         // Accessor-rule check

DDDPlusEnforcer

The DDDPlusEnforcer (located in dddplus-enforce/src/main/java/io/github/dddplus/DDDPlusEnforcer.java) validates core domain-model contracts. It ensures correct usage of IDomainExtension, proper pattern naming conventions, and valid router naming according to DDD-plus specifications.

ExtensionMethodSignatureEnforcer

The ExtensionMethodSignatureEnforcer (located in dddplus-visualization/src/main/java/io/github/dddplus/ast/enforcer/ExtensionMethodSignatureEnforcer.java) verifies that extension methods follow the required signature patterns (e.g., public static modifiers) and are placed in the correct packages.

AllowedAccessorsEnforcer

The AllowedAccessorsEnforcer (located in dddplus-visualization/src/main/java/io/github/dddplus/ast/enforcer/AllowedAccessorsEnforcer.java) guarantees that only declared accessor methods are used across the codebase, preventing unauthorized access patterns that violate architectural boundaries.

Configuring the Enforce Goal in Your Maven Build

Required Configuration Parameters

The EnforcerMojo requires two parameters to locate your source code:

• <rootPackage> – The base Java package containing your domain code (e.g., com.mycompany.myapp).
• <rootDir> – The source directories holding the Java files (typically src/main/java).

These are defined in the plugin configuration section of your pom.xml.

Binding to the Verify Phase

To integrate the check into your standard build lifecycle, bind the enforce goal to the verify phase. This ensures the architecture compliance check runs after tests but before packaging.

<build>
  <plugins>
    <plugin>
      <groupId>io.github.dddplus</groupId>
      <artifactId>dddplus-maven-plugin</artifactId>
      <version>${dddplus.version}</version>
      <executions>
        <execution>
          <id>enforce-architecture</id>
          <phase>verify</phase>
          <goals>
            <goal>enforce</goal>
          </goals>
          <configuration>
            <rootPackage>com.mycompany.myapp</rootPackage>
            <rootDir>src/main/java</rootDir>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Command-Line Execution for CI/CD Pipelines

For scenarios where you cannot modify the pom.xml or need to run the check independently, invoke the goal directly from the command line:

mvn io.github.dddplus:dddplus-maven-plugin:enforce \
    -DrootPackage=com.mycompany.myapp \
    -DrootDir=src/main/java

This approach is documented in the repository's README under the Architecture Guard section and is particularly useful for local debugging or CI steps that require explicit enforcement without altering project configurations.

GitHub Actions Integration Example

To automate compliance checks in a GitHub Actions workflow, add a dedicated step after your build and test phases:

name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: '11'
          distribution: 'temurin'
          cache: maven
      - name: Build & test
        run: mvn clean verify
      - name: Architecture compliance check
        run: |
          mvn io.github.dddplus:dddplus-maven-plugin:enforce \
              -DrootPackage=com.mycompany.myapp \
              -DrootDir=src/main/java

If any architectural rule is violated, the plugin throws a MojoExecutionException, causing the GitHub Actions job to fail and preventing the merge of non-compliant code.

Handling Enforcement Failures

When the dddplus-maven-plugin enforce goal detects a violation, it aborts the build with a MojoExecutionException. Maven treats this as a build error, halting the pipeline immediately.

The plugin logs specific status messages for each enforcer:

• DDDPlusEnforcer OK
• ExtensionMethodSignatureEnforcer OK
• AllowedAccessorsEnforcer OK

If any check fails, the corresponding error message indicates which architectural rule was violated, allowing developers to pinpoint and fix the issue before re-running the pipeline.

Summary

• The dddplus-maven-plugin enforce goal runs three core enforcers—DDDPlusEnforcer, ExtensionMethodSignatureEnforcer, and AllowedAccessorsEnforcer—to validate DDD-plus architectural compliance.
• Configure the plugin in your pom.xml by binding the enforce goal to the verify phase and providing the required rootPackage and rootDir parameters.
• For CI/CD pipelines, invoke the goal directly via command line or integrate it into workflow files (e.g., GitHub Actions) to gate deployments on architecture compliance.
• Violations trigger a MojoExecutionException, failing the build and preventing non-compliant code from reaching production.

Frequently Asked Questions

What happens when the dddplus-maven-plugin enforce goal finds a violation?

The plugin throws a MojoExecutionException, which Maven interprets as a build failure. This immediately halts the pipeline, preventing the packaging or deployment of the artifact. The console output identifies which specific enforcer (DDDPlusEnforcer, ExtensionMethodSignatureEnforcer, or AllowedAccessorsEnforcer) detected the violation, allowing developers to diagnose the architectural breach.

Can I run the dddplus-maven-plugin enforce goal without modifying the pom.xml?

Yes, you can invoke the goal directly from the command line using the fully qualified plugin name. Execute mvn io.github.dddplus:dddplus-maven-plugin:enforce -DrootPackage=com.mycompany.myapp -DrootDir=src/main/java. This approach is useful for local debugging or for CI/CD environments where you want to enforce compliance without altering the project's build configuration files.

Which Maven phase should the dddplus-maven-plugin enforce goal bind to?

The recommended phase is verify. Binding to verify ensures the architecture compliance checks run after unit and integration tests complete but before the final artifact is packaged. This placement prevents non-compliant code from being bundled into deployable artifacts while keeping the feedback loop early enough in the build lifecycle for rapid developer response.

What is the difference between DDDPlusEnforcer and ExtensionMethodSignatureEnforcer?

DDDPlusEnforcer validates high-level domain model contracts, such as correct implementation of IDomainExtension interfaces, proper pattern naming conventions, and router naming standards. In contrast, ExtensionMethodSignatureEnforcer focuses specifically on low-level code structure, verifying that extension methods adhere to required signatures (e.g., public static modifiers) and are located in the correct packages. Together, they ensure both conceptual domain integrity and technical implementation consistency.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}