Evolving a Clean, Pragmatic Architecture - A Craftsman's Guide
•
8 gostaram•1,654 visualizações
This document outlines an agenda and presentation on clean code architecture. It discusses modeling data with entities and value objects, organizing logic by extracting services and applying the onion architecture. It emphasizes testing to reduce fear, and protecting developers through simplicity and avoiding overengineering. The presentation emphasizes keeping data transfer objects lightweight and external to the domain.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Evolving a Clean, Pragmatic Architecture - A Craftsman's Guide
Semelhante a Evolving a Clean, Pragmatic Architecture - A Craftsman's Guide (20)
Mais de Victor Rentea
Mais de Victor Rentea (20)
Último
Último (20)
Evolving a Clean, Pragmatic Architecture - A Craftsman's Guide
- 1. The Art of Clean Code = The Next Chapter = victor.rentea@gmail.com ♦ ♦ @victorrentea ♦ VictorRentea.ro Evolving A Clean, Pragmatic Architecture A Craftsman's Guide Check out my ‘Clean Code – The Next Episode’ Deep Dive at Devoxx BE 2019 for more context
- 2. When something is painful but you can't avoid doing it… postpone it
- 3. When something is painful but you can't avoid doing it… delegate it
- 4. When something is painful but you can't avoid doing it… Do It More Often! "Bring The Pain Forward!"
- 5. Continuous Integration Pair Programming Continuous Refactoring Test-First "Bring The Pain Forward!" eXtreme
- 6. Are you Agile ?
- 9. Software Craftsmanship ProfessionalismTechnical Practices Code of EthicsDeliberate Practice
- 11. Victor Rentea Clean Code Evangelist VictorRentea.ro/#playlist best talks on: Lead Architect Internal Coach Software Craftsman Pair Programming, Refactoring, TDD Java Champion Founder C#
- 12. VictorRentea.ro @victorrentea victor.rentea@gmail.com Independent Technical Trainer & Coach HibernateSpring Java 8 Architecture, DDDDesign Patterns Clean Code Unit Testing, TDD Java Performance more…Scala 240+ days1500 devs6 years VictorRentea.rovictor.rentea@gmail.com 30 companies Posting daily on +Live-Trainingon 30K 3K 2K
- 13. VictorRentea.ro14 The most important principle in programming?
- 14. VictorRentea.ro15 Single Responsibility Principle EmployeeManager -read/persist -compute pay-roll -generate PDF report -manage projects vs
- 17. VictorRentea.ro18 Keep It Short & Simple Premature encapsulation is the root of all evilOverengineering – Adam Bien Simpler code Developer Happiness
- 18. VictorRentea.ro19 Invisible Magic to reduce effort and risk Protect the Developers ... Developer Comfort Avoid building an intrusive Custom Framework ( )
- 19. VictorRentea.ro Fear Kills Creativity Simplify Unit Testing - Strong regression defense Protect the Developers 21 Developer Safety
- 20. 23 Building Software Is this really how it feels ?
- 23. VictorRentea.ro27 Keep Struggling for a Can you predict the future ? What features will grow super-complex in time? Simple Design At all times!
- 24. VictorRentea.ro28 Overengineering Design Patterns Useless Abstractions Simple Code Suple Flexibile
- 25. VictorRentea.ro30 A Simple Architecture that Evolves to Match the Growing Complexity This talk is about…
- 26. VictorRentea.ro31 Core Principles Modeling Data Organizing Logic The Onion Architecture Tests. Fear. Agenda VictorRentea.ro
- 27. VictorRentea.ro You control them! Entities = your persistent data 32 Entity They simplify your logic
- 28. VictorRentea.ro33 Put small bits of highly reusable domain logic in your Domain Entities public class Customer { [...] public String getFullName() { return firstName + " " + lastName; } public void activate(User user) { if (status != Status.DRAFT) { throw new IllegalStateException(); } status = Status.ACTIVE; activatedBy = user; activatedDate = new Date(); } public boolean isActive() { return status == Status.ACTIVE; } public boolean canPlaceOrders() { return status == Status.ACTIVE && !isBann }
- 29. VictorRentea.ro34 activatedBy = user; activatedDate = new Date(); } public boolean isActive() { return status == Status.ACTIVE; } public boolean canPlaceOrders() { return status == Status.ACTIVE && !isBann } public void addAddress(Address address) { address.setCustomer(this); addresses.add(address); } public List<Address> getAddresses() { return unmodifiableList(addresses); } } public String toExportString() { return String.format("%s;%s;%d", firstName, lastName, isActive()?1:0); } BlOAt dAnGeR Fit Put small bits of highly reusable domain logic in your Domain Entities
- 30. VictorRentea.ro Entityid 35 Small Immutable Lombok? No persistent ID unlike an Entity Equal by value of all fields @Embeddable decompose large entities Value Object: a grouping of domain data VO public class Money { private final Currency currency; private final BigDecimal amount; public Money(Currency currency, BigDecimal amount) { this.currency = currency; this.amount = amount; } public Currency getCurrency() { return currency; } public BigDecimal getAmount() { return amount; } public boolean equals(Object other) { ... } } validate();
- 31. VictorRentea.ro Then, you expose data to UI 36 “canBeDeleted”: true UI has different goals Never expose your Entities in your API Given you have some domain logic to implement
- 32. VictorRentea.ro I like dumb DTOs (you'll see soon why) public fields ?! ! !.. VOEntityid Logic public class CustomerDto { private String fullName; private String phoneNumber; private Date birthDate; public final String getFullName return fullName; } public final void setFullName(S this.fullName = fullName; } public final String getPhoneNum return phoneNumber; } public final void setPhoneNumbe this.phoneNumber = phoneNumbe } public final Date getBirthDate( return birthDate; } public final void setBirthDate( this.birthDate = birthDate; } } 37 Form/Request View/Response DTO SearchCriteria/SearchResult Data Transfer Objects DTO Instead, expose in your API public class CustomerDto { public String fullName; public String phoneNumber; public Date birthDate; } dto.fullName = customer.getFullName(); "Light CQRS"
- 33. VictorRentea.ro38 Core Principles Modeling Data Organizing Logic The Onion Architecture Tests. Fear. Agenda
- 35. VictorRentea.ro Repository Facade Controller Infrastructure calls DTO ~ JSON DTO? MappingValidation "canBeDeleted":true Transactions Service Entity ≈ Application Service [DDD]
- 37. VictorRentea.ro42 Data Conversion VOEntityid DTO Mapper Logic API Domain CustomerDto dto = new CustomerDto(); dto.fullName = customer.getFullName(); dto.birthDate = customer.getBirthDate(); dto.phoneNumber = customer.getPhoneNumber(); CustomerDto dto = new CustomerDto(customer); Complex? ➔ Extract Mappers ➔ DTO constructors
- 40. VictorRentea.ro45 Validation ➢internal ➢external ➢ubiquitous ➢status-specific ➢@NotNull ➢if ➢on DTO ➢on Entity ➢both only fields queries always true null name is OK at saveDraft() validation groups @Autowired @ValidCity
- 41. VictorRentea.ro Logic ServiceFacade HOW? Entities VO OOP Start writing all domain logic in a https://www.amazon.com/Domain-Driven-Design- Tackling-Complexity-Software/dp/0321125215
- 42. VictorRentea.ro57 Mapper VOEntityid DTO Facade Facade Domain Service Domain Service Domain Services Read more about this approach in Java EE Patterns - Rethinking Best Practices, by Adam Bien Then extract logic into -To hide complexity: SRP -For Reuse: DRY ▪ between Facades or Services Evolutionary Approach: Start writing all domain logic in a Facade
- 43. VictorRentea.ro58 Keep DTOs out! parameters and return types Mapper VOEntityid DTO Facade Facade Domain Service Domain Service Domain Services speak your Domain Model Convert them to your Domain Objects ASAP DTOs are fragile under enemy control * I like them dumb (no logic)
- 44. VictorRentea.ro Fç Validate Data Façade Convert Data Implement Logic Aspects - Transactions - Logging - Exception Handling* - Access Control* Facade Roles DTO Validator Mapper Domain Service VOEntityid Controller
- 45. VictorRentea.ro What’s that? When a class grows too big (>~200 lines?) ➔ break it Extract when it Grows How? Look for a good class name that summarizes some of its methods Huh!? Then I extract? That’s it? Yup! Piece a cake! A Good Name He-he!☺ “There are only two things hard in programming: Cache Invalidation and Naming Things”
- 46. VictorRentea.ro61 SRP applied to reduce complexity not to generate 10-lines classes
- 49. VictorRentea.ro CustomerFacade saveCustomer() getCustomer() searchCustomer() saveCustomerPreferences() getCustomerPreferences() validateAddress() resetPassword() checkPassworStrength() CustomerPreferencesFacade saveCustomerPreferences() getCustomerPreferences() validateAddress() resetPassword() checkPassworStrength() CustomerOpsFacade saveCustomer() getCustomer() searchCustomer() Controller Extract when it Grows at the same level of abstraction Horizontal Splitting > 300 lines
- 50. VictorRentea.ro EmailService CompositeOrder Service 65 Separation by Layers of Abstraction OrderService DeliveryService Extract when it Grows Vertical Extraction more abstract, higher-level
- 53. VictorRentea.ro Developer Comfort is essential for Emerging Architectures
- 54. VictorRentea.ro n Jr. Architect (prev: Jr JS Developer) (last LOC: 10+ years ago)
- 55. VictorRentea.ro72 Core Principles Modeling Data Organizing Logic The Onion Architecture Tests. Fear. Agenda VictorRentea.ro
- 56. VictorRentea.ro73 VOEntityid Domain Service Domain Service The code you want to protect Put it in the domain module Priceless Domain Logic Domain Objects domain
- 60. VictorRentea.ro77 External Service DTO IAdapter Adapterimplements class OrderRepository implements IOrderRepo { public Order getById(id){ ... } } interface IOrderRepo { Order getById(id); } class OrderService { @Autowired IOrderRepository repo; ... { repo.getById(id); } } express your need in a domain interface… and implement it in a lower-level module… When you need to call outside… so nothing foreign enters your domain. Domain Service Domain Service <dependency> domain infrastructure
- 61. VictorRentea.ro78 calls Dependency Inversion Principle <dependency> higher-level module lower-level module "Best of OOP" - Uncle Bob Abstractions should not depend on details Low level classes are not visible
- 63. VictorRentea.ro An agnostic Domain lets you focus on YOUR logic
- 64. VictorRentea.ro84 VOEntityid Domain Service Domain Service IExtSrv Adapter IRepo What code would you protect? Put it in the domain module Interfaces for External Services you consume Interfaces for Repositories Priceless Domain Logic Domain Objects
- 65. VictorRentea.ro infra ExtSrv Adapter Repo implem 85 Façade DTO Validator Mapper VOEntityid Domain Service Domain Service IExtSrv Adapter IRepo F application The Onion Architecture Behold, a.k.a. Hexagonal, Ports-and-Adapters
- 67. VictorRentea.ro97 Façade DTO Validator Mapper VOEntityid Domain Service Domain Service IRepo Repo implem F application IExtSrv Adapter Adapter WS Interface DTO domain Pragmatic for decent apps, 2 modules are enough
- 69. VictorRentea.ro99 .facade .service .repo .infra com.myorg.myapp .order. … .product. … They grew too big! Let’s restructure it. Package Names .entity .order. … .product. … Clean Architecture that speaks in domain words - Uncle Bob
- 70. VictorRentea.ro Use-case Optimal Query 100 CALLS DEPENDS Modularizing the Monolith DTO Facade Infra .order. … .product. … EVENT TX FK? SELECT MICRO… "Light CQRS" com.myorg.myapp. consistency 😱 Majestic Monolith* Replication * Check out Axel Fontaine talks on that for great tips for transitioning from a monolith
- 72. VictorRentea.ro102 archunit.org ArchRule rule = classes().that().resideInAPackage("..service..") .should().onlyBeAccessed() .byAnyPackage("..controller..", "..service..");
- 77. VictorRentea.ro ▪ 7 Virtutes of a Good Object ▪ NULL – the worst mistake in IT - https://dzone.com/articles/the-worst-mistake-of-computer-science-1 ▪ The Clean Architecture: - http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html ▪ Some ☺ Programming Jargon - http://blog.codinghorror.com/new-programming-jargon/ ▪ Code quality: WTFs/minute - http://commadot.com/wtf-per-minute/ ▪ SOLID is WRONG - https://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong ▪ Good software is written 3 times - http://www.javaworld.com/article/2072651/becoming-a-great-programmer--use-your- trash-can.html ▪ Prezi-like effect in PowerPoint 2016: “Morph” ▪ Value Objects vs Entity - http://enterprisecraftsmanship.com/2016/01/11/entity-vs-value-object-the-ultimate-list-of- differences/ ▪ Extends is bad - http://www.yegor256.com/2016/09/13/inheritance-is-procedural.html Further Reading 122
- 78. VictorRentea.ro123 Agenda VictorRentea.ro Core Principles Modeling Data Organizing Logic The Onion Architecture Tests. Fear.
- 79. VictorRentea.ro124 Core Principles VictorRentea.ro Modeling Data Organizing Logic The Onion Architecture Tests. Fear. AgendaTakeaways
- 80. VictorRentea.ro125 VictorRentea.ro Tests. Fear. Organizing Logic The Onion Architecture Modeling Data KISS: Avoid overengineering Magic to protect your Developers Takeaways
- 81. VictorRentea.ro126 VictorRentea.ro Tests. Fear. Organizing Logic The Onion Architecture Enemy data KISS: Avoid overengineering Magic to protect your Developers in your DTOs: keep them out Takeaways
- 82. VictorRentea.ro127 VictorRentea.ro Tests. Fear. Extract when it Grows The Onion Architecture KISS: Avoid overengineering Magic to protect your Developers : for SRP or DRY Enemy data in your DTOs: keep them out Takeaways
- 83. VictorRentea.ro128 VictorRentea.ro Extract when it Grows The Onion KISS: Avoid overengineering Magic to protect your Developers : for SRP or DRY Enemy data in your DTOs: keep them out , DIP: domain agnostic to externals Tests. Fear. Takeaways (Adapt® them)
- 84. VictorRentea.ro129 VictorRentea.ro Extract when it Grows The Onion KISS: Avoid overengineering Magic to protect your Developers : for SRP or DRY Enemy data in your DTOs: keep them out , DIP: domain agnostic to externals Tests: let them smash your design Takeaways (Adapt® them)
- 87. VictorRentea.ro What's next for you?
- 88. VictorRentea.ro137 Put Passion In All That You Do!!
- 89. VictorRentea.ro138 ¡¡ PLEASE !! Hunt me down for questions!
- 90. Thank You! VictorRentea.ro Trainings, talks, goodies @VictorRentea Follow me for quality posts: victorrentea.ro/community Speaking Romanian? join me ¡¡ PLEASE !! Hunt me down for questions! Check out my other 2 sessions at Devoxx Belgium A SCALABILITY PROBLEM: OUT OF STICKERS AND KEY CHEAT-SHEETS YOU CAN DOWNLOAD AND PRINT THEM YOURSELF FROM VICTORRENTEA.RO