Build Artifacts

Until now, our only tool for demarcating architecture boundaries within our codebase has been packaged. All of our code has been part of the same monolithic build artifact.

A build artifact is the result of a (hopefully automated) build process. The currently most popular build tools in the Java world are Maven and Gradle. Imagine we had a single Maven or Gradle build script and we could call Maven or Gradle to compile, test, and package the code of our application into a single JAR file.

Dependency resolution

The main feature of build tools is dependency resolution. To transform a certain codebase into a build artifact, a build tool first checks if all artifacts the codebase depends on are available. If not, it tries to load them from an artifact repository. If this fails, the build will fail with an error before even trying to compile the code.

We can leverage this to enforce the dependencies (and thus, enforce the boundaries) between the modules and layers of our architecture. For each such module or layer, we create a separate build module with its own codebase and its own build artifact (JAR file) as a result. In the build script of each module, we specify only those dependencies to other modules that are allowed according to our architecture. Developers can no longer inadvertently create illegal dependencies because the classes are not even available on the classpath and they would run into compile errors.

Artifacts