This version is still in development and is not considered stable yet. For the latest stable version, please use Spring Modulith 1.3.1! |
Documenting Application Modules
The application module model created via ApplicationModules
can be used to create documentation snippets for inclusion into developer documentation written in Asciidoc.
Spring Modulith’s Documenter
abstraction can produce two different kinds of snippets:
-
C4 and UML component diagrams describing the relationships between the individual application modules
-
A so-called Application Module Canvas, a tabular overview about the module and the most relevant elements in those (Spring beans, aggregate roots, events published and listened to as well as configuration properties).
Generating Application Module Component diagrams
The documentation snippets can be generated by handing the ApplicationModules
instance into a Documenter
.
Documenter
-
Java
-
Kotlin
class DocumentationTests {
ApplicationModules modules = ApplicationModules.of(Application.class);
@Test
void writeDocumentationSnippets() {
new Documenter(modules)
.writeModulesAsPlantUml()
.writeIndividualModulesAsPlantUml();
}
}
class DocumentationTests {
private val modules = ApplicationModules.of(Application::class.java)
@Test
fun writeDocumentationSnippets() {
Documenter(modules)
.writeModulesAsPlantUml()
.writeIndividualModulesAsPlantUml()
}
}
The first call on Documenter
will generate a C4 component diagram containing all modules within the system.
The second call will create additional diagrams that only include the individual module and the ones they directly depend on on the canvas.
Using Traditional UML Component Diagrams
If you prefer the traditional UML style component diagrams, tweak the DiagramOptions
to rather use that style as follows:
-
Java
-
Kotlin
DiagramOptions.defaults()
.withStyle(DiagramStyle.UML);
DiagramOptions.defaults()
.withStyle(DiagramStyle.UML)
This will cause the diagrams to look like this:
Generating Application Module Canvases
The Application Module Canvases can be generated by calling Documenter.writeModuleCanvases()
:
Documenter
-
Java
-
Kotlin
class DocumentationTests {
ApplicationModules modules = ApplicationModules.of(Application.class);
@Test
void writeDocumentationSnippets() {
new Documenter(modules)
.writeModuleCanvases();
}
}
class DocumentationTests {
private val modules = ApplicationModules.of(Application::class.java)
@Test
fun writeDocumentationSnippets() {
Documenter(modules)
.writeModuleCanvases()
}
}
By default, the documentation will be generated to spring-modulith-docs
folder in your build system’s build folder.
A generated canvas looks like this:
Base package |
|
---|---|
Spring components |
Services
Repositories
Event listeners
Configuration properties
Others
|
Aggregate roots |
|
Published events |
|
Events listened to |
|
Properties |
|
It consists of the following sections:
-
The application module’s base package.
-
The Spring beans exposed by the application module, grouped by stereotype. — In other words, beans that are located in either the API package or any named interface package. This will detect component stereotypes defined by jMolecules architecture abstractions, but also standard Spring stereotype annotations.
-
Exposed aggregate roots — Any entities that we find repositories for or explicitly declared as aggregate via jMolecules.
-
Application events published by the module — Those event types need to be demarcated using jMolecules
@DomainEvent
or implement itsDomainEvent
interface. -
Application events listened to by the module — Derived from methods annotated with Spring’s
@EventListener
,@TransactionalEventListener
, jMolecules'@DomainEventHandler
or beans implementingApplicationListener
. -
Configuration properties — Spring Boot Configuration properties exposed by the application module. Requires the usage of the
spring-boot-configuration-processor
artifact to extract the metadata attached to the properties.