Many companies are using microservices these days, but for many smaller companies, the complexity that comes with a distributed system is out of the question. However, one of the primary benefits of microservices, decoupling, can be realized in a monolith. I created the following project to bring some of the advantages of microservices to monoliths. I’ve called it “microlith”. It is my magnum opus of architectures. I’ve invented nothing here, but combined a number of interesting concepts in a way I think is novel. I’ve taken the concepts of Domain Driven Design, Functional Programming, Algebraic Data Types, CQRS, Hexagonal Architecture, Reactive Systems, etc, etc and combined them in an elegant way to create an architecture for backend applications that solves many of the issues that arise from traditional “pancake style” (web tier / services tier / repository tier) architectures. When used properly, this architecture provides better guardrails for “good developer behavior”, as well as providing a framework for moving various business invariants from runtime checks to compile time (thanks to ADTs). Please take a look. I’d love your feedback. https://github.com/edreyer/microlith Oh, and this is 100% kotlin. This architecture is, for all practical purposes, not possible in Java. Update: Thanks for the comments! A clarification: This is a monolith. Internally, the code is structured so that each Bounded Context (DDD) is segregated. Communication between contexts happens internally using some lightweight CQRS-like tooling, but does not use the network (e.g. no Kafka required).

Looks interesting. And there are some similarities (at least in terms of motivation) with device control systems we are researching. Are you interested in doing a talk at https://www.meetup.com/KotlinMoscow/?

I wouldn't call anything involving both kafka and spring micro. I use quite a bit of Spring and uncharacteristically without a relational database. We're actually considering switching to Ktor as kotlin native is starting to look like that might work with that eventually. One important consideration for us is faster startup and lower memory usage.

Microservice arch deployed as monolith

is it what's called "distributed monolith" ?

I've always thought of microlith as backend + web frontend but this an interesting definition. Nice use of archunit too...haven't seen it used in a real project before but it's been on my list of things to try 🙂

@deviant No the distributed monolith is when you have a monolith deployed over distributed services. Here, the services appear to all deploy in the same place. @Erik Dreyer What benefits does this project have over simply inverting dependencies with interfaces, segregating code using regular library modules, and deploying everything inside one binary without involving kafka/spring before they are needed?

Thanks for the comments! To clarify, this is a monolith. Internally, the way in which you structure your application is such that it’s like you’ve bundled microservices together. The idea is to gain the benefits of microservice architectures, namely segregation of duties, but without having to have a distributed system, or rely on messaging systems like Kafka. One potential upside to this is that when you are actually ready to implement a real distributed system, it is fairly trivial to move each bounded context out of your monolith, and into your microservice. There is no hairball to untangle.

One potential upside to this is that when you are actually ready to implement a real distributed system, it is fairly trivial to move each bounded context out of your monolith, and into your microservice

I see this as one of the primary benefits. Because it’s already being tested via spring, its probably more likely to move out to a microservice without issues. However, I don’t think this will actually help with the hairball part of the problem. It’s still easy to make a hairball with fully distributed services. Hexagonal and DDD help, but I’m still unclear how this project helps implement those. By nature the implementation of these are domain specific. How can something that’s not domain specific help?

Hexagonal and DDD help, but I’m still unclear how this project helps implement those. By nature the implementation of these are domain specific. How can something that’s not domain specific help?

Right. When you compare a system like this to a traditional 3 tiered, layered approach (controllers / services / repositories) there are much better guardrails for how you structure your business logic. For example, in the traditional approach, use cases are implicit. The logic is spread throughout a variety of Services. It’s been my experience that it can even span multiple layers. Services over time become very broad. I’ve seen Service classes that autowire in 20 or more other services, DAOs, etc. This approach doesn’t prevent this, but it provides some mechanisms/guardrails to better reason about your domain and structure it in such a way as to prevent this. More here: https://reflectoring.io/book/

Oh yeah, I was probably less clear. I love and use Hexagonal and DDD. Both super helpful. I’m just unsure how microlith provides helpful guardrails. In my experience, these things add friction which can be both positive and negative. When working in an environment that would have otherwise produced good architecture, the friction makes it harder to do the right change. When working in an environment that would have otherwise produced poor architecture, it can produce friction that prevents negative change, but also friction to prevent positive change. I'm not a fan of needing to add inheritance to validate my architecture. That tends to add rigidity to the code. I'm also not a fan of adding these kinds of hard boundaries too early. One of the benefits of hexagonal is that you can start off your module small, with no layers, no ports, no adapters, etc. And as it grows, gets more complex, etc, you can invert dependencies as it makes sense. Good architecture should allow you to make as little decisions as possible. This feels like I'm committing to too many decisions, too early.

Fair points. One possible (and valid) approach to use this would be to put everything into a single bounded context to start. As you learn more about your domain, you can choose at any time to split part of the domain out into a 2nd BC (3rd, etc). I’d only caution a team using this to stay mindful of how entangled various aggregates become inside that single BC.

All good insight, thanks for responding to my feedback!

Thanks for your comments! I appreciate the dialog.

I like starting my new features as 1-tier to start. No database, no api. Ok maybe two, because separation of UI from logic.

btw more common term is modulith

I was wondering if there was a term. Thanks! Now I have to go rename it.

Interesting project, having a better look tomorrow! I created something somewhat similar, with the main difference being; introducing hard boundaries enforcing the separation of business logic and adapters. https://github.com/ESchouten/CleanArchitecture