Let's adopt the `clean archigonal`
summary
Argues that both Hexagonal and Clean isolate the business core from tech, demonstrated with a Java hotel-reservation example using interfaces as ports, JPA as one adapter option, and TDD where the first adapter is a test double so the unit test covers the whole hexagon as a behavior and stays green through refactor. Claims Clean gives more internal guidance (presenter, entities) while Hexagonal is looser, and recommends choosing the pattern by domain complexity rather than as a silver bullet.
AI-written summary · about
chapters (7)
- 0:00Introduction and speaker intro
- 3:33Why software architecture matters
- 15:50History of software architecture
- 26:29Hexagonal architecture explained
- 31:32Clean architecture deep dive
- 39:32Choosing between architectures
- 42:03Q&A session
related talks
50mAdopt the Clean Archigonal
01h 01mWhy not all hexagons have eight sides
52mWhy not all hexagons have eight sides
50mClean Architecture with Spring
45mWhy Hexagonal and Onion Architecture Are Answers to The Wrong Question
46mHexagonal at Scale, with DDD and microservices!
21mTestable Architecture: Keep 'em Separated
51mDomain-centric? Why Hexagonal- and Onion-Architecture are answers to the wrong question