InfoQ Homepage Presentations Building Better Monoliths: Implementing Modulithic Applications with Spring
Building Better Monoliths: Implementing Modulithic Applications with Spring
01:00:36
Summary
Oliver Drotbohm identifies the common issues in unstructured monoliths and discusses approaches to package design, component structure, transactions, and the usage of events.
Bio
Oliver Drotbohm is a Senior Principal Software Engineer, Pivotal.
About the conference
Pivotal Training offers a series of hands-on, technical courses prior to SpringOne Platform. Classes are scheduled two full days before the conference and provide you and your team an opportunity to receive in-depth, lab-based training across some of the latest Pivotal technologies.
Jan 02, 2020
Community comments
Did he just re-invent OSGi?
by Doug Ly,
Re: Did he just re-invent OSGi?
by Greg Liebowitz,
Re: Did he just re-invent OSGi?
by Oliver Drotbohm,
Did he just re-invent OSGi?
by Doug Ly,
Your message is awaiting moderation. Thank you for participating in the discussion.
He didn't mention OSGi in this talk. Based on the presentation his proposal seems to be the exact thing OSGi tries to resolve.
Re: Did he just re-invent OSGi?
by Greg Liebowitz,
Your message is awaiting moderation. Thank you for participating in the discussion.
This seems to provide metadata that can be used to enforce modularity and detect architectural violations, not an implementation of a module system.
Re: Did he just re-invent OSGi?
by Oliver Drotbohm,
Your message is awaiting moderation. Thank you for participating in the discussion.
Not at all. The idea is to create a (tweakable) out of the box module convention that can be inspected and verified via an API preferably via tests. That module model can then be used through a Spring Boot testing extension to only bootstrap parts of the application in integration tests.
So while there are certain goals shared with OSGi, most OSGi features or implementation ideas are not relevant here: no classloader isolation (to avoid the additional technical complexity and that kind of isolation not being necessary for the cases assumed here), no dynamic services, no hot reloading of artifacts, no required explicit description of exposed packages via a text file (but rather a convention of defaults plus annotations to tweak those).