Builiding Modular monoliths that can scale to microservices. JBCNConf 2021

It’s easy these days to fall into the trap of starting to design your whole application with a microservices architecture…. Because, you know, that’s what everyone is doing. Aren't they?
But, are we considering the microservices architecture as a goal or as a means to a purpose?

In this talk, we will go back to the basics and see how DDD, CQRS and EventSourcing practices drive our application design and evolution so that we will start with a monolith. Still, we will have the ability to scale into microservices more or less easily when (and more importantly: if) we need to.

These are the slides I used in my talk at JBCNConf 2021

Transcript

1. David Gómez G. Developer Advocate . Building monolith applications that can scale to micro services (only if they need to) @AXONIQ @DGOMEZG
2. Don’t let the microservices hype ruin your project @DGOMEZG @AXONIQ @DGOMEZG David Gómez G. Developer Advocate .
3. An Exciting New Project Starts @DGOMEZG
4. Or you may need to add a new module/feature to an existing project @DGOMEZG
5. But this time, you are going to get it right! @DGOMEZG
6. We need to scale! We need to go to the cloud(s)! @DGOMEZG
7. How others solved similar problems? @DGOMEZG
8. @DGOMEZG Microservices architecture
9. @DGOMEZG Microservices architecture
11. How others solved similar problems? @DGOMEZG
12. You will probably be missing
13. @DGOMEZG Hype Driven Development HDD
14. Problems seem easier to solve when you have enough context @DGOMEZG
15. we don’t usually know enough @DGOMEZG @DGOMEZG
16. we don’t usually know enough @DGOMEZG
17. @DGOMEZG What you need (Your steps) • Separate your different tasks by type • Focus on understanding the problem(s) you need to solve, • Model each problem independently • Be prepared to grow & scale (both in features and in performance) • Don’t couple to other components
18. @DGOMEZG Our example: A Conference Management Tool.
19. @DGOMEZG Our example A Conference Management Tool. Dates, Sponsors, Call For Papers, Proposals, Agenda T alks, Tickets, Attendees… Call For Papers, Agenda, Questions, Forums, Tickets, Agenda, speakers, …
20. @DGOMEZG Event Storming
21. @DGOMEZG Command Query Responsibility Separation CQRS
22. @DGOMEZG COMMANDS QUERIES CQRS Separate Queries from Commands
23. @DGOMEZG CQRS Separate Queries from Commands COMMANDS What actions do require changes in the state of the application? What other changes will be necessary to notify/propagate?
24. @DGOMEZG CQRS Separate Queries from Commands COMMANDS De fi ne Edition (Dates) Accept/Reject Talk Proposal Open Ticket sales Open Call For Papers Add/Remove Track De fi ne Q&A Channel Submit Proposal Withdraw Proposal Con fi rm Proposal Join Q&A Channel Buy Ticket Add Talk To My Agenda Ask Questions in Q&A. Rate Talk
25. @DGOMEZG CQRS Separate Queries from Commands QUERIES What information do the users require?
26. @DGOMEZG CQRS Separate Queries from Commands QUERIES List Proposals Get Talk Popularity Get Talks Rating Get Questions Get Talk Feedback My Talk Info Conference Agenda My Agenda Q&A Messages
27. @DGOMEZG Queries UI / API Commands
28. @DGOMEZG Model with Boundaries DDD
29. https://www.flickr.com/photos/xwl/4936781806/
30. Which map would you prefer? It depends!
31. @DGOMEZG COMMANDS QUERIES Focus on modelling within the boundaries of each element Command model Projections Keep only relevant information for the action in each model
32. @DGOMEZG JoinRoom JoinRoom Send Message Command model CreateChatRoom NAME, DESCRIPTION USER, ROOMID, MSG JoinRoom USERID, ROOMID
33. @DGOMEZG Projections Projections maintain the structure of information close to how it is needed by the client/user ListRooms ROOM, DESCRIPTION, NUM_OF_MEMBERS GetRoomMessages DATE, USER, MSG DATE, USER, MSG DATE, USER, MSG
34. @DGOMEZG Aggregate A set of objects, relationship and invariants that are considered as one unit with regard to data changes. De fi ne the boundaries in which some invariants are kept. They are a model of part of the domain.
35. @DGOMEZG Aggregate
36. @DGOMEZG Queries UI / API Commands Command Model Projections ?
37. @DGOMEZG To the rescue! Events
38. Source: https://principles.reactive.foundation (Recommended read!)
39. Remember our micro services architecture?
40. Remember our micro services architecture?
41. Remember our micro services architecture?
42. Remember our micro services architecture? Event
43. @DGOMEZG Queries UI / API Commands Command Model Projections ?
44. @DGOMEZG Queries UI / API Commands Command Model Projections Events
45. @DGOMEZG Event Modeling http://eventmodeling.org
46. @DGOMEZG Event-Streaming vs Event-Sourcing
47. Event-Streaming
48. Event-Streaming
49. Why Event-Streaming?
50. Why Event-Sourcing? ProposalUpdated (id: 123, title) SpeakerAdded (id:123, jDoe) ProposalSubmitted ProposalAccepted ProposalWithdrawn ProposalDraftSen t (id: 123) id: 123. Author: John Doe Title: What’s new in Java 17 status: WIthdrawn What happened What we store
51. Why Event-Sourcing? Business Reasons Technical reasons • Reliability of decisions • Auditing / compliance / transparency • Data mining, analytics: value for data • Historic data useful for new features • Guaranteed completeness of event stream • Single point of truth • Concurrency / con fl ict resolution • Facilitates debugging / forensic analysis • Replay into new read models (scalability with CQRS)
52. @DGOMEZG Location Transparency (Enabled by Events)
53. Location Transparency A component should neither be aware of nor make any assumptions about the location of other components Even more… Should not even know which components it interacts with
54. Location Transparency A component should neither be aware of nor make any assumptions about the location of other components Even more… Should not even know which components it interacts with
55. Location Transparency A component should neither be aware of nor make any assumptions about the location of other components Even more… Should not even know which components it interacts with
56. Location Transparency A component should neither be aware of nor make any assumptions about the location of other components Even more… Should not even know which components it interacts with
57. Location Transparency A component should neither be aware of nor make any assumptions about the location of other components Even more… Should not even know which components it interacts with
59. 1. Keep the independent models
60. 1. Keep the independent models
61. 1. Keep the independent models
62. 1. Keep the independent models CQRS + DDD
63. Event Sourcing (sync modules) + Message Bus Event store
64. @DGOMEZG Putting it together
65. Command Model data class CreateRoomCommand( @TargetAggregateIdentifier val roomId: String, val name: String) data class JoinRoomCommand( @TargetAggregateIdentifier val roomId: String, val participant: String) data class PostMessageCommand( @TargetAggregateIdentifier val roomId: String, val participant: String, val message: String) data class LeaveRoomCommand( @TargetAggregateIdentifier val roomId: String, val participant: String)
66. Event Model data class RoomCreatedEvent( val roomId: String, val name: String) data class ParticipantJoinedRoomEvent( val roomId: String, val participant: String) data class MessagePostedEvent( val roomId: String, val participant: String, val message: String) data class ParticipantLeftRoomEvent( val roomId: String, val participant: String)
67. Aggregate @Aggregate public class ChatRoom { @AggregateIdentifier private String roomId; private Set<String> participants; public ChatRoom() { } }
68. Aggregate: Handling a Command @Aggregate public class ChatRoom { @AggregateIdentifier private String roomId; private Set<String> participants; @CommandHandler public ChatRoom(CreateRoomCommand command) { apply(new RoomCreatedEvent(command.getRoomId(), command.getName())); } @CommandHandler public void handle(JoinRoomCommand command) { apply(new ParticipantJoinedRoomEvent(command.getRoomId(), command.getParticipant())); } }
69. Aggregate: Handling a Command @Aggregate public class ChatRoom { @AggregateIdentifier private String roomId; private Set<String> participants; @CommandHandler public void handle(JoinRoomCommand command) { apply(new ParticipantJoinedRoomEvent(command.getRoomId(), command.getParticipant())); } @EventSourcingHandler public void on(ParticipantJoinedRoomEvent event) { this.participants.add(event.getParticipant()); } }
70. Location Transparency. Sync other components @Component public class RoomSummaryProjection { private final RoomSummaryRepository roomSummaryRepository; @EventHandler public void on(RoomCreatedEvent event) { roomSummaryRepository.save(new RoomSummary(event.getRoomId(), event.getName())); } @EventHandler public void on(ParticipantJoinedRoomEvent event) { roomSummaryRepository.findById(event.getRoomId()) .ifPresent(RoomSummary : : addParticipant); } }
71. In summary
72. @DGOMEZG Hype Driven Development HDD
73. @DGOMEZG HDD CQRS DDD Event- Sourcing
74. Useful Resources https://lp.axoniq.io/jbcnconf The slides Code-sample & tutorial repo Free DDD, CQRS & ES courses eventmodeling.org Domain-Driven Design lp.axoniq.io/jbcnconf Axon OS tools Link to ask for your t-shirt