Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023
•
7 likes•2,765 views
In this presentation we will present the general philosophy of Clean Architecture, Hexagonal Architecture, and Ports & Adapters: discussing why these approaches are useful and general guidelines for introducing them to your code. Chiefly, we will show how to implement these patterns within your Spring (Boot) Applications. Through a publicly available reference app, we will demonstrate what these concepts can look like within Spring and walkthrough a handful of scenarios: isolating core business logic, ease of testing, and adding a new feature or two.
Report
Share
More Related Content
What's hot
What's hot (20)
Similar to Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023
Similar to Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023 (20)
More from Steve Pember
More from Steve Pember (20)
Recently uploaded
Recently uploaded (20)
Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023
- 1. Anatomy of a Spring Boot App with Clean Architecture Steve Pember Senior Staff @ Stavvy, Inc Spring I/O 2023
- 2. @svpember
- 3. @svpember
- 5. @svpember Today ● What is Software Architecture? ● Clean Architecture, an Overview ● Anatomy of a Spring App with Clean Architecture ● Demo App
- 6. @svpember What Even Is Software Architecture?
- 7. @svpember
- 12. @svpember Some Benefits of a Well Architected Code Base ● Separation of Concerns / Modularity ● Flexibility ● Testability ● Maintainability ● Development Velocity “Slow is Fast”
- 13. Software Architecture is the set of Structures to Guide Future development…
- 14. @svpember … and the discipline to adhere to those structures
- 15. @svpember
- 17. There are many Architecture Patterns, for Specific situations. Focus on ‘Broad’ ones
- 18. @svpember Broadly Useful Patterns ● Ports and Adapters ● Hexagonal Architecture ● Onion ● SOLID + Clean Architecture
- 21. @svpember
- 22. @svpember Common features ● Layering + Separate Boundaries ● Agnostic, Encapsulated Core Domain ● Inversion of Control
- 25. @svpember Clean Highlights 1. S.O.L.I.D. 2. Component Principles 3. Boundaries & Dependencies 4. Nearly Everything is Just A “Detail”
- 26. @svpember 1) Your Code Should Follow SOLID Principles ● (S)ingle Responsibility: a class should only have one responsibility, or one reason to change; used by a single user Role ● (O)pen-closed: “open for extension, closed for modification” (aka use interface implementation, Delegation, or Strategy patterns) ● (L)iskov’s substitution: aka “behavioral subtyping”; implementations/sub-classes should adhere to client expectations. ● (I)nterface segregation: code should not depend on methods it does not use (create more, smaller classes and interfaces) ● (D)ependency inversion: “depend upon abstractions, not concretions” (dependency injection using interfaces)
- 27. @svpember 2) Component Principles ● A “Component” is the ideal boundary ● Partition a system into isolated, independently developable structures ● Components are handed out to teams ● Components should be able to be individually compiled, built, and tested ● Components should be Loosely Coupled
- 28. 2) Component Principles Microservices are the ultimate Component
- 29. Difficult to Design Components “Top Down”
- 30. @svpember 2) Component Principles Avoid Dependency Cycles: relationships should form a D.A.G!
- 31. 3) Boundaries and Dependency Flow
- 32. @svpember Entities & Services Component HTTP Component AWS component Stripe component Postgres Component Main Data Flow
- 33. @svpember 3) Boundaries and Dependency Flow Simple Structures (method calls) going IN, Interfaces going OUT
- 34. Outer layers may only see what is in an Inner layer!
- 35. Inner Layers Should Be Immune To Outer
- 36. @svpember
- 37. @svpember
- 38. @svpember 4) Nearly Everything is an Implementation Detail ● Maintain Flexibility by separating code into “Policy” and “Details” ● Everything not in your “Core” is a Detail.
- 39. Defer Making Decisions about Details For As Long As You Can
- 40. @svpember 4.1) Your Database Is A Detail ● Are we using Postgres? ● Mysql? ● Dynamodb? ● Redis? ● … it doesn’t matter. Not Really.
- 41. @svpember 4.1) Your Database Is A Detail
- 42. @svpember 4.1) Your Database Is A Detail
- 43. A Quick Tangent: Don’t Think About Your Schema First
- 44. Makes me a tiny bit crazy
- 45. @svpember 4.2) The Environment Is A Detail ● Your code must not know or care where it is being run ○ Local laptop ○ QA environment ○ Inside a Docker Container on Kubernetes ○ Production on an ec2 instance ○ Bare Metal DataCenter ○ Integration Test Suite ● … it doesn’t matter ● Avoid “environment specific” configuration ● Inject Environment Variables or fetch Config Values dynamically
- 46. 4.3) Input Is A Detail
- 47. 4.3) Input Is A Detail
- 48. … 4.4) Even The Framework Is A Detail
- 49. @svpember Spring And the JVM
- 50. @svpember Clean Arch Examples ● Modules & Subprojects ● Controllers / HTTP Input ● Message Input ● Profiles + Env vars ● Testing ● “Output” Repositories
- 52. @svpember ⅓ - The Core ● Contains your core business logic ● Entities ● “Use Cases” / Service Classes ● Lightweight DTOs ● Interfaces ● Logging and Metrics? (Use Slf4j & Micrometer)
- 53. @svpember ⅔ - The Details ● The Implementations of Interfaces ● Detail-Specific Class Structures ● External Clients ● SQL ● Good place for database Migrations
- 54. @svpember 3/3 - The App ● AKA “Where Spring Lives” ● Application Configuration ● Application Lifecycle ● “Input” (e.g. Controllers) ● Impossible to Clean; the “Dirtiest” of components
- 55. @svpember Hide Your Internals ● Not Everything needs to be “public” ● module-info.java
- 56. These 3 are just a start. Plan on growing.
- 57. @svpember Input: HTTP / Controllers ● Simple: Use Spring Web / MVC ● Controllers should be as minimal as possible: ○ Convert User Input ○ Handle AuthZ / AuthN (use Filters) ○ Call into Core Services via function calls or lightweight objects
- 58. @svpember Input: Messages / Queues ● Use Observer Pattern ● Connect / Disconnect In Spring Lifecycle Listeners ● Spring Integration & MessageTemplate
- 59. @svpember Service Classes ● Closest to “Use Cases” ● Keep them small and focused: Remember: Single Use ● Avoid “OrderService”, prefer “CustomerOrderQueryService” ○ It’s more specific and evocative! ● Almost all of them will live in Core
- 60. @svpember Created as @Beans manually Or
- 61. @svpember Profiles and Env Vars ● Configuration should be Environment Agnostic ● Avoid Profiles for Environment Specific Config ○ Profiles are for profile-based things. ● Inject Env Vars ● Take a look at Spring Cloud Config and Spring Cloud Vault!
- 63. @svpember Testing ● Components -> Fast Unit Tests ● Integration Tests go in the “App” Component ● Testcontainers (and Localstack) FTW!
- 64. @svpember Testing Suite Launches TestContainers! Spring Dynamic Configuration update to talk To the containers!
- 65. @svpember Datastores ● Remember: databases and stores are tools ● Everything goes behind a Repository Interface ● Implementation goes in the Details Module ● Databases, Caches, Microservice calls, Third Parties
- 66. @svpember Put JPA components behind a boundary
- 67. @svpember Time to Pray to the Demo Gods
- 68. Sure, following ‘Clean’ adds more Files & more mapping code…
- 69. … But it is an excellent way to achieve that “Guardrail Balance”
- 70. Thank You!
- 71. @svpember Any Questions? Also happy to chat afterwards!
- 72. @svpember Links ● Twitter: @svpember ● Example Code Repo: https://github.com/spember/spring-shoestore ●
- 73. @svpember Images ● Blueprint: ● Messy IT closet ● Boxes of Spaghetti: ● Cars not crashing ● Car Crash ● Cobra Kai ● Dog Jump ● Tightrope Walker ● Immune System ● Blanket ● Crying Baby