Pragmatic Monolith-First, easy to decompose, clean architecture
1 like5,458 views
The document discusses a pragmatic approach to software architecture advocating for a monolith-first strategy that is easy to decompose and promotes clean architecture principles. It covers key architectural solutions and practices that can help manage complexity, integrate bounded contexts, and prepare for transitioning to microservices. The author emphasizes the importance of understanding the domain, proper packaging, and the iterative refactoring process to improve scalability and maintainability.
![# prevent cyclic dependencies
check acyclicCompositionOf com.acme.someservice
[usecase] = com.acme.someservice.*.usecase.*
[domain] = com.acme.someservice.*.domain.*
[adapter] = com.acme.someservice.*.adapter.*
[delivery] = com.acme.someservice.*.delivery.*
# domain is independent of usecase
check [domain] directlyIndependentOf [usecase]
check [delivery] directlyIndependentOf [dziedzina]
# delivery constraints
check [usecase] directlyIndependentOf [delivery]
check [adapter] directlyIndependentOf [delivery]
check [domain] directlyIndependentOf [delivery]
# only heagonal architecture structure
check deny *
check allow com.acme.someservice.*.usecase.*
check allow com.acme.someservice.*.domain.*
check allow com.acme.someservice.*.adapter.*
check allow com.acme.someservice.*.delivery.*
# except technical packages
check allow com.acme.someservice.technical.*](https://image.slidesharecdn.com/monoloth-first-171120211259/85/Pragmatic-Monolith-First-easy-to-decompose-clean-architecture-58-320.jpg)
Pragmatic Monolith-First, easy to decompose, clean architecture
- 1. Pragmatic Monolith-First easy to decompose, clean architecture Piotr Pelczar Gliwice 2017, Spread IT
- 2. Let’s design a system • Several different products • Multi Channel
- 3. System Architecture - Case Accounts DepositsLoans
- 4. System Architecture - Case Product API GUI Channel 1 GUI Channel 2 • Simple Split-Architecture (GUI + backend)
- 5. System Architecture - Case Accounts DepositsLoans
- 6. Business makes money and want to scale • Cross-sell
- 7. System Architecture - Case Accounts DepositsLoans
- 8. System Architecture - Case Accounts Loans
- 9. System Architecture - Case
- 10. System Architecture - Solution 1 Accounts Loans Event Bus Loans’ • Event-Driven + data duplication
- 11. System Architecture - Solution 2 Accounts Repo Loans Accounts Sales Process • Refactor – move functionality to another module
- 12. System Architecture - Solution 2 Accounts Repo Loans Repo Accounts Sales Process Loans Sales Process • And more refactor…
- 13. Business makes Cross-sell and want to scale • Sell next type of Loan
- 14. “We want the same process.”
- 15. “… almost the same process, but…”
- 16. System Architecture - Case Accounts Repo Loans Repo Loans Sales Process Dep #1 Dep #2 Dep #3
- 17. System Architecture - Solution 1 Accounts Repo Loans Repo Loans Sales Process Dep #1 Dep #2 Dep #3 Dep #4 Dep #5 • if, if, if, if • strategy pattern (hidden if), chain of responsibility • more dependencies
- 18. System Architecture - Solution 2 Loans Sales Process Dep #1 Dep #2 Dep #3 Dep #4 Dep #5 • Design new process and bring some stuff to common The Next one Loan Sales Process C #1 C #1 C #1Commons:
- 19. Is it good decision?
- 20. Accounts Loans …or this coupling is acceptable? Can we assume that it is essential complexity not accidental complexity?
- 21. Piotr Pelczar Java, Groovy, node.js, PHP 11 yrs exp
- 22. We are making mistakes Let’s prepare for them better
- 23. Microservices hype We know benefits We know drawbacks One Bounded Context = 1 µS Do we split properly? Do we understand Business?
- 24. Why not Microservices at the beginning? • YAGNI • True: Hard to scale poor designed successful software • But it is better than have failed software but well designed • You need to be agile at the beginning • Works good only with well separated Bounded Contexts • You have to learn domain first • Refactoring in monolith is much simpler than in microservices https://martinfowler.com/bliki/MonolithFirst.html
- 26. Monolith-First Architecture Manifest: • Build well-managed complexity monolith • Easy to refactor (move between packages) • Enables quick pivots in Domain Modeling • Exposes ready to peel-off edges into microservices Idyll?
- 27. Monolith-First Architecture For: • Long-living components (many projects) • with Complex domain (no CRUD)
- 28. 1. Well done high-level packaging
- 29. 1. Well done high-level packaging • Open the app folder and can easily recognize what it is about
- 30. 1. Well done high-level packaging • Packaging by technical layer = Monoloth RIP • More than one Bounded Context in each layer = cannot split them
- 31. 1. Well done high-level packaging Packaging by business scopes/Bounded Context = easy to split com.acme.SERVICE-NAME.BOUNDED-CONTEXT.*
- 32. 2. Know your domain
- 33. 2. Know your domain Modeling - DDD gives us tools: • Tactical: (how to organize code) • Aggregates, Value Objects, Repositories, Events • Application Services, Domain Services (transforming data, integration) • Strategic: (how to map and discover domain) • Problem mapping • Bounded Contexts
- 34. 2. Know your domain
- 35. 2. Know your domain Event Storming – reveal domain by asking “what happened? when?” Alberto Brandolini https://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design
- 36. 2. Know your domain - DDD "Software development is a learning process; working code is a side effect." In monolith we can start with: • Rich domain • Pilled-off bounded contexts (high level packages)
- 37. 3. Encapsulate the domain (Clean Architecture and Usecases)
- 38. 3. Encapsulate the domain • On top-level packages expose what application do • not how it is devlivered • Use Case is Application Service pattern from DDD It orchestrates the domain
- 40. @Service public class CreateScheduleUC { @Transactional public void createSchedule(CreateScheduleCommand command, CreateScheduleResult result) { ScheduleId newScheduleId = scheduleRepository.generateNextId(); ProgrammeId programmeId = ProgrammeId.of(command.getProgrammeId()); final Schedule newSchedule = Schedule.create( newScheduleId, programmeId ); scheduleItemsMapper.mapItemsToDomain(newSchedule, command.getItems()); scheduleConstraintsMapper.mapConstraintsToDomain(newSchedule, command.getConstraints()); scheduleRepository.save(newSchedule); result.success(newScheduleId.getId()); } }
- 44. @Service public class FindScheduleForDayUC { @Data @Builder public static class ScheduleForDayCommand { private final String programmeId; private final LocalDate day; } public interface ScheduleForDayResult { void success(Schedule schedule); void notExists(); } public void findScheduleForDay(ScheduleForDayCommand command, ScheduleForDayResult result) { // ... result.notExists(); // ... result.success( ... ); } }
- 45. @Controller @RequestMapping("/schedule") class FindScheduleForDayController { @GetMapping(value = "/forDay/{programmeId}/{day}") @ResponseBody @ApiResponses({ @ApiResponse(code = 200, message = "", response = ScheduleDto.class), @ApiResponse(code = 404, message = ""), }) public ResponseEntity<?> createSchedule(@RequestParam("programmeId") String @RequestParam("day") @DateTimeFormat ScheduleForDayCommand command = ... FindScheduleForDayResponseBuilder responseBuilder ... findScheduleForDayUC.findScheduleForDay(command, responseBuilder); return responseBuilder.toResponse(); } }
- 46. 3. Clean architecture UI Business Logic DAO I/O … Business Logic Domain GUI DAO I/O
- 48. 4. Make gaps in domain Port and Adapters aka Hexagonal Architecture
- 49. 4. Make gaps in domain • Ports (red) • Adapters (blue) • Out • In • I like “delivery” instead of “in adapters” http://www.dossier-andreas.net/software_architecture/ports_and_adapters.html
- 50. 4. Make gaps in domain • Separates domain from dependencies • Database • Another Bounded Context • Domain Services can map foreign domain to our domain • Forum Author instead of User • Product parameters instead of Product from catalogue http://www.dossier-andreas.net/software_architecture/ports_and_adapters.html
- 51. 5. Integrate Bounded Contexts
- 52. 5. Integrate Bounded Contexts • Integrate via Ports -> Adapters -> referring to Usecases • Almost Microservices! http://www.natpryce.com/articles/images/ports-and-adapters-acceptance-testing.png
- 53. But we live in monolith… and easy to make some unwanted dependencies
- 57. 6. Manage Complexity • Structure 101 • Java • PHP • Socomo Maven Plugin • Java • Another tools?
- 58. # prevent cyclic dependencies check acyclicCompositionOf com.acme.someservice [usecase] = com.acme.someservice.*.usecase.* [domain] = com.acme.someservice.*.domain.* [adapter] = com.acme.someservice.*.adapter.* [delivery] = com.acme.someservice.*.delivery.* # domain is independent of usecase check [domain] directlyIndependentOf [usecase] check [delivery] directlyIndependentOf [dziedzina] # delivery constraints check [usecase] directlyIndependentOf [delivery] check [adapter] directlyIndependentOf [delivery] check [domain] directlyIndependentOf [delivery] # only heagonal architecture structure check deny * check allow com.acme.someservice.*.usecase.* check allow com.acme.someservice.*.domain.* check allow com.acme.someservice.*.adapter.* check allow com.acme.someservice.*.delivery.* # except technical packages check allow com.acme.someservice.technical.*
- 59. 7. You are ready to peel-off edges
- 60. 7. Peel-off edges 1. Move whole package to another service • add delivery layer only 2. Change Use Cases invocations in Adapters to RPC
- 61. 7. Peel-off edges public class AuthorFromUserService implements AuthorProvider { public Author getAuthor(String nickname) { User user = someUsecase.getUserByUsername(nickname); Author author = //... return author; } } Old Use Case invocation:
- 62. 7. Peel-off edges public class AuthorFromUserService implements AuthorProvider { interface UserService { @RequestLine("GET /users/{username}") User getUserByUsername(@Param("username") String username); } public Author getAuthor(String nickname) { User user = userService.getUserByUsername(nickname); Author author = //... return author; } }
- 63. Monolith-First Architecture 1. Well done packaging 2. Know your domain (strategic and tactic DDD) 3. Encapsulate the domain (Clean Architecture and Usecases) 4. Make gaps in domain (Port and Adapters) 5. Integrate Bounded Contexts 6. Manage complexity (by CI tools) 7. You are ready to peel-off edges
- 64. We are making mistakes Let’s prepare for them better
- 65. Monolith-First Architecture For: • Long-living components (many projects) • when is a good time to peel-off? • with Complex domain (no CRUD)
- 66. Monolith-First Architecture • Many buzzwords? These patterns already exists there name is “interfaces” here they are structured