This document summarizes a meetup on modularizing monolithic applications. It discusses benefits of modularization like slimmer, simpler code with reduced bugs and clear dependencies. Costs include complex API governance and fragmented deployments. Decoupling patterns for OSGi and content are presented, like glue bundles, optional dependencies, overlays, and feature extraction. Modularized testing is also discussed as a combinatorial nightmare to optimize.

1. APACHE SLING & FRIENDS TECH MEETUP
2-4 SEPTEMBER 2019
From monolith to modules
Dominik Süß, Robert Munteanu, Adobe
1

2. Welcome
2

3. About us
Dominik Süß
Software Engineer
Robert Munteanu
Senior Computer Scientist
3

4. Outline
Benefits vs cost of modularization
Decoupling patterns
Tooling support
Keeping QA effort under control
4

5. Modularisation
5

6. Benefits
SlimmerSlimmerSlimmerSlimmerSlimmer
SimplerSimplerSimplerSimplerSimpler
Reduced impact of bugsReduced impact of bugsReduced impact of bugsReduced impact of bugsReduced impact of bugs
Clear dependenciesClear dependenciesClear dependenciesClear dependenciesClear dependencies
Decoupled module lifecyclesDecoupled module lifecyclesDecoupled module lifecyclesDecoupled module lifecyclesDecoupled module lifecycles
6

7. Costs
Complexity of API GovernanceComplexity of API GovernanceComplexity of API GovernanceComplexity of API GovernanceComplexity of API Governance
Planning & Testing for absence of modulesPlanning & Testing for absence of modulesPlanning & Testing for absence of modulesPlanning & Testing for absence of modulesPlanning & Testing for absence of modules
Complexity & Fragmentation of deployment &Complexity & Fragmentation of deployment &Complexity & Fragmentation of deployment &Complexity & Fragmentation of deployment &Complexity & Fragmentation of deployment &
maintenance proceduresmaintenance proceduresmaintenance proceduresmaintenance proceduresmaintenance procedures
Additional aspect to development flow & toolingAdditional aspect to development flow & toolingAdditional aspect to development flow & toolingAdditional aspect to development flow & toolingAdditional aspect to development flow & tooling
7

8. We need a plan...
Global API to modularized APIGlobal API to modularized APIGlobal API to modularized APIGlobal API to modularized APIGlobal API to modularized API
Extend & integrate toolingExtend & integrate toolingExtend & integrate toolingExtend & integrate toolingExtend & integrate tooling
Start cuttingStart cuttingStart cuttingStart cuttingStart cutting
8

9. Decoupling patterns - OSGi
9

10. Glue bundles
Billing MessagingBilling
Messages
10

11. Glue bundles
 Encapsulates the dependencies
 Refactoring to a glue bundle can be difficult
 Glue bundles need to be explicitly deployed
when needed
11

12. Optional dependencies
<Import-Package>
com.example.billing.api;resolution:=optional
,*
<Import-Package>
12

13. Optional dependencies
@Component(enabled=false)
public class MyComponent { /* ... */ }
@Component
public class MyComponentStarter {
protected void activate(ComponentContext ctx) {
try {
log.info("Found class {}", BarImpl.class);
ctx.enableComponent(MyComponent.class.getName());
} catch ( Throwable t) {
log.info("Foo component unavailable due to
missing Bar module", t);
}
}
}
13

14. Optional dependencies
 Minimal impact on existing code bases
 Unnatural pattern to prevent ERROR log entries
 Indicator of low cohesion
14

15. Overlays
public interface Foo { }
@Component
public class MyConsumer {
@Reference(policyOption = ReferencePolicyOption.GREEDY)
private Foo foo;
}
@Component // default service.ranking of 0
public class DefaultFooImpl implements Foo { }
@Component(property = {
Constants.SERVICE_RANKING +":Integer=100"
})
public class MyBetterFooImpl implements Foo { }
15

16. Overlays
 Simple and well-understood mechanism of
overriding service references
 Requires consumers to mark references as greedy
 Service ranking are complicated to manage for
large numbers of implementations
16

17. Feature extraction
17

18. Feature extraction
 Usually cleans up incorrect layering
 Dependencies can spiral out of control
18

19. Decoupling patterns - content
19

20. Glue components
private static final RenderCondition INSTANCE =
new RenderCondition() {
@Override
public boolean check() {
try {
new Handlebars();
return true;
} catch (NoClassDefFoundError e) {
return false;
}
}
};
20

21. Glue components
 Minimal impact on existing code bases
 Established AEM pattern
 Pushes modularity at the class, instead of the
bundle level
21

22. Overlays
<execute
jcr:primaryType="nt:unstructured"
sling:resourceType="some/workflow/step">
<executor
jcr:primaryType="nt:unstructured"
className="com.adobe.foreign.module.ExecutorImpl"/>
</execute>
22

23. Overlays
 Minimal impact on existing code bases
 Can lead to surprising behaviour at runtime
23

24. Decoupling patterns - generic
24

25. Inlining
Rule of three → write, duplicate, refactor
Code duplication is a smell, not a crime
Refactoring and abstractions are costly
25

26. Decoupling patterns - generic
26

27. Moving checks at build time
Build time  Test Time  Run Time
[ERROR] Bundle org.apache.sling.caconfig.spi:1.3.4 is importing
package(s) org.apache.sling.api.resource in start level 20 but
no bundle is exporting these for that start level.
27

28. Potential areas for extension
Validate content-package Java imports are
satisfied
Generate constraints for discovered workflow
steps
28

29. Modularised testing
29

30. Modularised testing
Combinatorial nightmareCombinatorial nightmareCombinatorial nightmareCombinatorial nightmareCombinatorial nightmare
Optimize CI/CD pipeline to act on module levelOptimize CI/CD pipeline to act on module levelOptimize CI/CD pipeline to act on module levelOptimize CI/CD pipeline to act on module levelOptimize CI/CD pipeline to act on module level
30

31. Summary
31

32. Impact of AEM modularisation
 Reduced API surface
 Faster install and startup times
 Lower memory usage
 Reduced disk footprint
 More complex development and testing
scenarios
32