Monolith VS. Microservice 3 Module A Module B Module C Module B Module C Module A Bounded Context Deployment Unit Internal invocation External invocation
Monolith 4 The application packages the implementation of multiple Bounded Contexts as a single deployment unit. Easy to refactor Easy to test the overall system Likely to degrade unless explicitly managed Harder to test individual Bounded Contexts
Microservices 5 A bounded context defines the boundaries of the deployment artifact. Often parts of the context are even deployed as separate processes. ○ Bounded Context interaction is remote ○ Testing individual modules Hard to refactor context boundaries Hard to test the overall system
Moduliths 13 1. A convention to map contexts to packages Packages directly nested underneath the main application package are considered context ones. 2. Test support to bootstrap modules Integration with Spring test context framework and Spring Boot integration test support to limit bootstrap (component & entity scanning) to only the involved packages.
15 package com.acme @Modulith // Instead of @SpringBootApplication class MyApplication { … } package com.acme.moduleA @ModuleTest // Instead of @SpringBootTest class MyModuleTests { … } Applies package conventions Bootstraps single module for test
Dependency types 24 1. Simple type dependency References to aggregates and entities of other modules. 2. Component dependency References to other Spring beans, required to bootstrap the module 3. Events & event listeners Dependency on some other module’s event type. Interesting as they’re great hooks for testing.
Dependency types 25 1. Simple type dependency References to aggregates and entities of other modules. 2. Component dependency References to other Spring beans, required to bootstrap the module 3. Events & event listeners Dependency on some other module’s event type. Interesting as they’re great hooks for testing. ☝Avoid!
Bootstrap modes 28 1. Standalone Bootstraps the module the test is contained in. Components in other modules the bootstrapped module depends on need to be provided through @MockBean. 2. Direct dependencies Bootstraps the module including the modules it directly depends on. Transitive dependencies have to be mocked just like in standalone mode. 3. All dependencies Bootstraps the entire sub-tree of modules starting from the current one.
Moduliths 29 1. A convention to map contexts to packages Packages directly nested underneath the main application package are considered context ones. 2. Test support to bootstrap modules Integration with Spring test context framework and Spring Boot integration test support to limit bootstrap (component & entity scanning) to only the involved packages. 3. Simple set of access rules and API to verify Only access components in module API packages.
Some conventions… 30 01 10 M M 01 10 Allowed by the compiler Allowed by Moduliths Rejected by the compiler Rejected by Moduliths Public Package protected Bounded Context Java Package
API Package Convention 34 ….modulith ….modulith.moduleA ….modulith.moduleA.internal ….modulith.moduleB ….modulith.moduleB.internal Access to components residing in internal packages forbidden and checked during tests.
Moduliths 37 1. A convention to map contexts to packages Packages directly nested underneath the main application package are considered context ones. 2. Test support to bootstrap modules Integration with Spring test context framework and Spring Boot integration test support to limit bootstrap (component & entity scanning) to only the involved packages. 3. Simple set of access rules and API to verify Only access components in module API packages. 4. Documentation support PlantUML integration via Simon Brown’s Structurizr to document module structure and dependency types.
Multiple Artifacts 40 Every module port becomes a dedicated build artifact. Dedicated control over dependencies Test scope is defined by the artifact Potential explosion of number of artifacts Internal structure visible to the outside
Java Module System 41 Every module becomes a Java 9+ module. ○ Strong coupling between module and artifact ○ Semantics of the „opens“ keyword ○ No test support
External Tools 42 External tools (e.g. jQAssistant, Sonargraph, jDepend) integrated into the build and executed in the CI environment are used to signal structural violations. Most extensive option Distance to development workflow
Moduliths 43 1. A convention to map contexts to packages Packages directly nested underneath the main application package are considered context ones. 2. Test support to bootstrap modules Integration with Spring test context framework and Spring Boot integration test support to limit bootstrap (component & entity scanning) to only the involved packages. 3. Simple set of access rules and API to verify Only access components in module API packages. 4. Documentation support PlantUML integration via Simon Brown’s Structurizr to document module structure and dependency types.
Resources 44 Moduliths Project website on GitHub Majestic Modular Monoliths Video on Youtube Modular Monoliths Simon Brown – Video on YouTube Refactoring to a System of Systems Video on YouTube
olivergierke
mackee
hollycummins
kinakomoti321
inouehi
kubotak
n1215
aanrii
hcrane
kanamasa
fendo181
yutootsuka
blackbracken
bkeepers
michaelherold
sonatard
vanstee
morganepeng
maltzj
bryan
quramy
addyosmani
tammielis
chrislema
paulrobertlloyd