“You shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile.” - Martin Fowler We won’t. We will look at building (and build) a Majestic Monolith that can easily be refactored to microservices if and when the need arises. From DevNexus 2022

1. 7 Strategies for Building
Majestic Monoliths
Jeremy Davis
Chief Architect
jeremy.davis@redhat.com
@argntprgrmr

2. DHH
Reference

3. 7 Strategies
1: DDD and Bounded Contexts
2: APIs First
3: Make Data Autonomous
4: Avoid Bottlenecks
5: Commit to Continuous(ish) Delivery
6: Embrace Code Quality
7: Citadels and Outposts

4. Supersonic, Subatomic Java and Other Technologies Used in this Presentation

5. Tame Complexity! And Responsibility Creep
1: DDD and
Bounded
Contexts

6. com.redhat.summit.majesticmonolith.web.infrastructure
Domain Driven Design and Bounded Contexts
6
Monolithically Speaking It’s All About Your Package Design

7. Match Your Package Structure to Your Bounded Contexts
7
Shared Domain and Utils are OK (for now)

8. Domain Driven Design and Bounded Contexts
8
Domain, Infrastructure, Value Objects, Repositories

9. How would you like to consume your code?
2: API’s First

10. com.redhat.summit.majesticmonolith.barista.api
Code Is Read More Often Than It Is Written
10
Leave A Clean, Elegant Trace
Provide an “.api” package
Method names should be logical and easy to understand
Document exhaustively
Minimize mutability
Follow the Principle of Least Astonishment
Fail fast and expressively

11. 3: Make Data
Autonomous

12. com.redhat.summit.majesticmonolith.barista.domain
com.redhat.summit.majesticmonolith.counter.domain
com.redhat.summit.majesticmonolith.kitchen.domain
Don’t Fret the Duplication of Datasources
12
MVC It’s Not Like You Have to Write Much Boilerplate Anymore Anyway

13. Be Asynchronous!
4: Avoid
Bottlenecks

14. com.redhat.summit.majesticmonolith.barista.domain
Scaling Before You Have to Scale Up or Out
14
Asynchronous, Reactive, Message Based

15. com.redhat.summit.majesticmonolith.barista.domain
Scaling Before You Have to Scale Up or Out
15
Asynchronous, Reactive, Message Based

16. Tekton (or another solution)
5: Commit to
Continuous(ish) Delivery

17. Pipelines are key
17

18. 6: Embrace Code
Quality

19. com.redhat.summit.majesticmonolith.barista.domain
Jacoco, PMD, SpotBugs
19
Coverage, Style, Bugs, and More

20. 7: Citadels and
Outposts

21. Contact the Outpost
21
Kafka is Great

22. debezium.io
Contact the Outpost
22
Debezium Outbox Pattern and Plugin

24. Links
24
DDD and Bounded Contexts
Domain Driven Design: Tackling Complexity in the Heart of Software
Domain Driven Design Distilled
Domain Driven Design for Mere Mortals - DevNation Tech Talk
Domain Driven Design on InfoQ
API’s First
Designing APIs: the other User Interface - Burk Hufnagel (Youtube)
How To Design A Good API and Why it Matters - Joshua Bloch (Youtube)
Make Data Autonomous
Reliable Microservices Data Exchange with the Outbox Pattern
Event Sourcing vs CDC

25. More links
25
Avoid Bottlenecks
Quarkus Guides: Getting Started With Reactive
Commit to Continuous(ish) Delivery
The present and future of CI/CD with GitOps on Red Hat OpenShift
Embrace Code Quality
Quarkus Guides: Tests with Coverage
Jacoco
PMD (Project Mess Detector)
Spotbugs
Citadels and Outposts
The Majestic Monolith Can Become the Citadel - David Hannemeir Hanson