Download as PDF, PPTX
![46
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
}](https://image.slidesharecdn.com/cleanarchitecturejbcnconf-190528170343/75/Evolving-a-Clean-Pragmatic-Architecture-at-JBCNConf-2019-29-2048.jpg)
![63
Start implementing all domain logic in a
Facade
Mapper VOEntityid
DTO
Facade
Facade Domain
Service
Domain
Service
Domain Services
This approach is detailed in Java EE Patterns - Rethinking Best Practices, by Adam Bien
Then extract logic into
-To hide complexity: SRP
-For Reuse: DRY
▪ (across Facades or Services)
≈ Application Service
[DDD]](https://image.slidesharecdn.com/cleanarchitecturejbcnconf-190528170343/75/Evolving-a-Clean-Pragmatic-Architecture-at-JBCNConf-2019-36-2048.jpg)
Uploaded byVictor Rentea
Evolving a Clean, Pragmatic Architecture at JBCNConf 2019
The document emphasizes the importance of embracing painful tasks in software development by either postponing, delegating, or facing them directly. It discusses agile practices, continuous integration, and architectural principles like the onion architecture while advocating for simplicity and minimizing overengineering. The talk also addresses the need for developer safety and comfort, encouraging practices such as pair programming and proper coding designs to enhance productivity and quality.
In this document
Powered by AI
Methods for managing unavoidable painful tasks: postpone, delegate, or confront them more often.
Discussion on Agile practices, Continuous Integration, and Software Craftsmanship principles.
Introduction to Victor Rentea's expertise and activities in software development and training.
Important programming principles including Single Responsibility, Coupling, Don't Repeat Yourself.
Focus on creating a comfortable and safe environment for developers, emphasizing regular brainstorming and unit testing.
Focus on creating a comfortable and safe environment for developers, emphasizing regular brainstorming and unit testing.
Kent Beck's rules for simple design and adaptive architecture to meet growing complexity.
Core principles of modeling data, organizing logic, and utilizing domain entities within architecture.
The importance of using DTOs (Data Transfer Objects) while separating domain logic from API exposures.
Utilizing Facade and Mapper patterns to manage complex logic and improve code simplicity.
Guidance on breaking down large classes and maintaining logical separation in application architecture.
Discussion on impacts of code duplication and the benefits of pair programming for quality assurance.
Emphasizing developer comfort as a key factor in adopting and evolving architecture effectively.
Advocacy for increased unit testing to bolster developer confidence and lead to simpler production code.
Expression of gratitude and encouragement to put passion in all endeavors.
Overview of key principles: KISS (Keep It Simple), protecting developers, and adaptive architecture.
More Related Content
Similar to Evolving a Clean, Pragmatic Architecture at JBCNConf 2019
Evolving a Clean, Pragmatic Architecture at JBCNConf 2019
- 2. When something ispainful but you can't avoid doing it… postpone it
- 3. When something ispainful but you can't avoid doing it… delegate it
- 4. When something ispainful but you can't avoid doing it… Do It More Often! "Bring The Pain Forward!"
- 5. Continuous Integration Pair Programming ContinuousRefactoring TDD eXtreme Programming "Bring The Pain Forward!"
- 6.
- 7.
- 8. Victor Rentea Clean CodeEvangelist VictorRentea.ro 30+ talks, 12 meetups .NET Lead Architect Tech Team Lead and Consultant Software Craftsman XP: Pair Programming, Refactoring, TDD Java Champion
- 9. VictorRentea.ro @victorrentea victor.rentea@gmail.com Independent TechnicalTrainer & Coach HibernateSpring Java 8 Architecture, DDDDesign Patterns Clean Code Unit Testing, TDD Java Performance and much more…Scala 180+ days1300 devs6 years VictorRentea.rovictor.rentea@gmail.com 30 companies Posting daily on
- 13. 28 The most importantprinciple in programming?
- 14. 29 Single Responsibility Principle EmployeeManager -read/persist -computepay-roll -generate PDF report -manage projects vs
- 15.
- 16.
- 17. 32 Keep It Short& Simple Premature encapsulation is the root of all evilOverengineering – Adam Bien
- 18. 33 Keep It Short& Simple Premature encapsulation is the root of all evilOverengineering Simpler code Developer Happiness
- 19. 34 Invisible Magic toreduce effort and risk Protect the Developers ... Avoid building an intrusive Custom Framework (bugs to learn) Developer Comfort
- 20. 35 Request/Thread Scope @Autowired private MyRequestContextrequestContext; ... { entity.setModifiedBy(requestContext.getCurrentUser()); } @Component @Scope(value = "request", proxyMode = TARGET_CLASS) class MyRequestContext { ... } Request Metadata
- 21. Fear Kills CreativitySimplify Unit Testing - Strong regression defense Protect the Developers 36 Developer Safety
- 22. Always Think Regular Brainstorming 37 ContinuousRefactoring There are NO boring tasks automate them
- 23.
- 24. 41 No? Then Keep Strugglingfor a Can you predict the future ? What features will evolve super-complex in time? Simple Design At all times!
- 25. 42 - Kent Beck https://martinfowler.com/bliki/BeckDesignRules.html 2.Reveals Intention 3. No Duplication 4. Fewest Elements 1. Passes the Tests Rules of Simple Design
- 26. 43 A Simple Architecture thatEvolves to Match the Growing Complexity This talk is about…
- 27. 44 Core Principles Modeling Data OrganizingLogic The Onion Architecture Tests. Fear. Agenda VictorRentea.ro
- 28. You control them! Entities= your persistent data 45 Entity They simplify your logic
- 29. 46 Put small bitsof 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 }
- 30. 47 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 Collections.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
- 31. Entityid 48 Small Immutable Lombok? No persistent ID unlikean Entity Equal by value of all fields Embeddable In larger 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();
- 32. Then, you startexposing data to UI (SPA, WS, JSF, desktop) UI has different goals They want data structures to match their screens. Never expose your Entities in your API 49 isDeletable: true (to show the Delete button)
- 33. I like dumbDTOs (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; } } 50 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();
- 34. 51 Core Principles Modeling Data OrganizingLogic The Onion Architecture Tests. Fear. Agenda
- 35. 52 Complex Conversion? Extract Mappers VOEntityid DTO Mapper Logic APIDomain CustomerDto dto = new CustomerDto(); dto.fullName = customer.getFullName(); dto.birthDate = customer.getBirthDate(); dto.phoneNumber = customer.getPhoneNumber(); CustomerDto dto = new CustomerDto(customer);
- 36. 63 Start implementing alldomain logic in a Facade Mapper VOEntityid DTO Facade Facade Domain Service Domain Service Domain Services This approach is detailed in Java EE Patterns - Rethinking Best Practices, by Adam Bien Then extract logic into -To hide complexity: SRP -For Reuse: DRY ▪ (across Facades or Services) ≈ Application Service [DDD]
- 37. 65 Keep DTOs out! (parametersand 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 methods)
- 38. Fç Validate Data Façade Convert Data ImplementLogic Aspects - Transactions - Logging - Exception Handling* - Access Control* 66 Facade Roles DTO Validator Mapper Domain Service VOEntityid
- 39. 67 What do youmean ? When a class gets too big (>~200 lines?) ➔ break it Extract when it Grows How? Find a good class name to summarize some of its methods If I find a good name, I extract? That’s it? Exactly! Piece a cake! A Good Name He-he!☺ “There are only two things hard in programming: Cache Invalidation and Naming Things”
- 40. 68 SRP applied to reducecomplexity
- 41. 69 CustomerFacade saveCustomer() getCustomer() searchCustomer() saveCustomerPreferences() getCustomerPreferences() validateAddress() resetPassword() checkPassworStrength() CustomerPreferecesFacade saveCustomerPreferences() getCustomerPreferences() validateAddress() resetPassword() checkPassworStrength() CustomerFacade saveCustomer() getCustomer() searchCustomer() Controller Extract when itGrows at the same level of abstraction Horizontal Splitting > 300 lines
- 42. AlertService CompositeOrder Service 70 Separation by Layersof Abstraction OrderService DeliveryService Extract when it Grows Vertical Extraction more abstract, more higher-level
- 43. 72 Duplication Pair Programming Imposed validate inJS/TS and in Java Rush/Lazy Inadvertent you forget and implement it again Inter-developer you didn't knew that was already implemented (Δt=5-10s) bus factor =2
- 44.
- 45.
- 46. Developer Comfort is essentialfor Emerging Architectures
- 47.
- 48. 78 Core Principles Modeling Data OrganizingLogic The Onion Architecture Tests. Fear. Agenda VictorRentea.ro
- 49. 79 VOEntityid Domain Service Domain Service What code wouldyou protect? Put it in the domain module Priceless Domain Logic Domain Objects domain
- 50.
- 51.
- 52. 82 External Service DTO Adapter Domain Service Domain Service <dependency>domain infrastructure A hugeAdapter® Pattern - Hide their ugly API - Handle their Exceptions - Decouple their DTOs your Entities - Validate their evil data
- 53. 83 External Service DTO IAdapter Adapterimplements class OrderRepository implementsIOrderRepo { 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
- 54. 84 calls Dependency Inversion Principle <dependency> higher-level module lower-level module "Bestof OOP" - Uncle Bob Abstractions should not depend on details Low level classes are not visible
- 55.
- 56.
- 57. 90 VOEntityid Domain Service Domain Service IExtSrv Adapter IRepo What code wouldyou protect? Put it in the domain module Interfaces for External Services you consume Interfaces for Repositories Priceless Domain Logic Domain Objects
- 58.
- 59.
- 60.
- 61. 104 facade domain (+repo) infrastructure com.myorg.myapp. .order. … .product. … Thisgrew too big! I need to restructure it.
- 62. Use-case Optimal Query 105 CALLS DEPENDS Breakinga Monolith DTO Facade Infra .order. … .product. … EVENT TX FK? SELECT MICRO… "Light CQRS" com.myorg.myapp. consistency 😱 "Clean Architecture" Replicate?
- 63.
- 64.
- 65.
- 66.
- 67.
- 68. 114 Core Principles Modeling Data OrganizingLogic The Onion Architecture Tests. Fear. Agenda
- 69. 115 Lots of UnitTests are Good ! A sense of confidence Developer Courage Continuous Refactoring (It’s still a single )
- 70. 116 As you fightto write Unit Tests, the Production code gets simpler
- 71. 118 First couple ofunit tests : The most valuable Test no. difficulty
- 72. Maintainable Tests Pure Functions Noside effects. No dependencies. Mock-based In-memory Emulation or JPQL tests on H2/* db Fragile data fixtures On Real Systems Eg: Connecting to a real DB 119 𝑓 𝑥, 𝑦 = 𝑥2 + 𝑦2
- 73. infrastructure domain side effects 122 pure logic UnitTesting Like a Pro (the circle of purity)
- 74. ▪ 7 Virtutesof 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 ▪ “Measure Don’t Ask” is TM of Kirk Pepperdine Further Reading 127
- 75. 128 Agenda VictorRentea.ro Core Principles Modeling Data OrganizingLogic The Onion Architecture Tests. Fear.
- 76. 129 Core Principles VictorRentea.ro Modeling Data OrganizingLogic The Onion Architecture Tests. Fear. AgendaTakeaways
- 77. 130 VictorRentea.ro Tests. Fear. OrganizingLogic The Onion Architecture Modeling Data KISS: Avoid overengineering Magic to protect your Developers Takeaways
- 78. 131 VictorRentea.ro Tests. Fear. OrganizingLogic The Onion Architecture Enemy data KISS: Avoid overengineering Magic to protect your Developers in your DTOs: keep them out Takeaways
- 79. 132 VictorRentea.ro Tests. Fear. Extractwhen 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
- 80. 133 VictorRentea.ro Extract whenit 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)
- 81. 134 VictorRentea.ro Extract whenit 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)
- 82.
- 83.
- 84. 142 Put Passion In AllThat You Do!!
- 85.