Downloaded 73 times
![VictorRentea.ro59
public class LDAPUserServiceAdapter {
private LdapContext ctx;
...
public LdapUserSearchResult findAccountByAccountName(String ldapSearchBase, String accountName) {
try {
String searchFilter = "(&(objectClass=user)(sAMAccountName={1}))";
SearchControls searchControls = new SearchControls();
searchControls.setSearchScope(SearchControls.SUBTREE_SCOPE);
NamingEnumeration<SearchResult> results = ctx.search(
ldapSearchBase, searchFilter, new Object[]{accountName} searchControls);
if (!results.hasMoreElements())
return null;
}
SearchResult searchResult = (SearchResult) results.nextElement();
if (results.hasMoreElements()) {
throw new MyAppException(ErrorCode.DUPLICATE_USER_IN_LDAP);
}
return new LdapUserSearchResult(searchResult);
} catch (NamingException e) {
throw new MyAppException(ErrorCode.LDAP_LOOKUP_FAILED);
}
}
}
External Service Adapter
.
.
.
.
.](https://image.slidesharecdn.com/cleanarchitecture-prezentatlajpoint2017-180525145654/85/Clean-Pragmatic-Architecture-Avoiding-a-Monolith-59-320.jpg)
![VictorRentea.ro59
public class LDAPUserServiceAdapter {
private LdapContext ctx;
...
public LdapUserSearchResult findAccountByAccountName(String ldapSearchBase, String accountName) {
try {
String searchFilter = "(&(objectClass=user)(sAMAccountName={1}))";
SearchControls searchControls = new SearchControls();
searchControls.setSearchScope(SearchControls.SUBTREE_SCOPE);
NamingEnumeration<SearchResult> results = ctx.search(
ldapSearchBase, searchFilter, new Object[]{accountName} searchControls);
if (!results.hasMoreElements())
return null;
}
SearchResult searchResult = (SearchResult) results.nextElement();
if (results.hasMoreElements()) {
throw new MyAppException(ErrorCode.DUPLICATE_USER_IN_LDAP);
}
return new LdapUserSearchResult(searchResult);
} catch (NamingException e) {
throw new MyAppException(ErrorCode.LDAP_LOOKUP_FAILED);
}
}
}
External Service Adapter
.
.
.
.
.](https://image.slidesharecdn.com/cleanarchitecture-prezentatlajpoint2017-180525145654/75/Clean-Pragmatic-Architecture-Avoiding-a-Monolith-59-2048.jpg)
Uploaded byVictor Rentea
Clean Pragmatic Architecture - Avoiding a Monolith
This document outlines key principles for creating clean and pragmatic architecture in enterprise Java applications, emphasizing concepts such as single responsibility, avoiding duplication, and maintaining simplicity. It discusses techniques like dependency inversion, favoring composition over inheritance, and the benefits of pair programming. Overall, the material serves as a guide for best practices in software development to enhance maintainability and developer comfort.
More Related Content
Similar to Clean Pragmatic Architecture - Avoiding a Monolith
Clean Pragmatic Architecture - Avoiding a Monolith
- 1. Enterprise Java Training VictorRentea.ro victor.rentea@gmail.com @victorrentea ©Copyright Victor Rentea 2017 Victor Rentea 22 feb 2017 Brainstorming a Clean Pragmatic Architecture Single Responsibility Principle High Cohesion A method should do only ONE thing. A class should have only 1 reason to change..?
- 2. Enterprise Java Training VictorRentea.ro victor.rentea@gmail.com @victorrentea ©Copyright Victor Rentea 2017 Victor Rentea 22 feb 2017 Brainstorming a Clean Pragmatic Architecture Don’t Repeat Yourself Never duplicate logic (Capital Sin). Extract-and-Invoke. Antonym: Write Everything Twice.
- 3. Enterprise Java Training VictorRentea.ro victor.rentea@gmail.com @victorrentea ©Copyright Victor Rentea 2017 Victor Rentea 22 feb 2017 Brainstorming a Clean Pragmatic Architecture Keep It Short & Simple Keep It Simple, Stupid - US Navy Systems work best if kept simple. Avoid overengineering at all costs.
- 4. Enterprise Java Training VictorRentea.ro victor.rentea@gmail.com @victorrentea ©Copyright Victor Rentea 2017 Victor Rentea 22 feb 2017 Brainstorming a Clean Pragmatic Architecture Loose Coupling Classes with few dependencies.
- 5. Enterprise Java Training VictorRentea.ro victor.rentea@gmail.com @victorrentea ©Copyright Victor Rentea 2017 Victor Rentea 22 feb 2017 Brainstorming a Clean Pragmatic Architecture You Ain’t Gonna Need It Extreme Programming Don’t add functionality until deemed necessary. Implement things when you actually need them, NOT when you just foresee that you need them.
- 6. Enterprise Java Training VictorRentea.ro victor.rentea@gmail.com @victorrentea ©Copyright Victor Rentea 2017 Victor Rentea 22 feb 2017 Brainstorming a Clean Pragmatic Architecture Yoda Conditions if ("a".equals(param)) { Avoids NPE. Equals FEAR?
- 7. Enterprise Java Training VictorRentea.ro victor.rentea@gmail.com @victorrentea ©Copyright Victor Rentea 2017 Victor Rentea 22 feb 2017 Brainstorming a Clean Pragmatic Architecture Favor Composition Over Inheritance GoF A extends B is bad. Use composition: a.setB(b);
- 8. Enterprise Java Training VictorRentea.ro victor.rentea@gmail.com @victorrentea ©Copyright Victor Rentea 2017 Victor Rentea 22 feb 2017 Brainstorming a Clean Pragmatic Architecture NOPping Stanislav sat watching the screensaver and nopped for a while.
- 9. Enterprise Java Training VictorRentea.ro victor.rentea@gmail.com @victorrentea ©Copyright Victor Rentea 2017 Victor Rentea 22 feb 2017 Brainstorming a Clean Pragmatic Architecture Pair Programming Two programmers working together on one PC. The driver writes code, the navigator reviews it. They switch often. Is cheaper on long-run.
- 10. Enterprise Java Training VictorRentea.ro victor.rentea@gmail.com @victorrentea ©Copyright Victor Rentea 2017 Victor Rentea 22 feb 2017 Brainstorming a Clean Pragmatic Architecture Dependency Inversion Principle Abstractions should not depend on details. Details should depend on abstractions.
- 11. Enterprise Java Training VictorRentea.ro victor.rentea@gmail.com @victorrentea ©Copyright Victor Rentea 2017 Victor Rentea 22 feb 2017 Brainstorming a Clean Pragmatic Architecture
- 12. @ VictorRentea.ro Spring and CleanCode, Design Patterns TDD, Coding Dojos Java Performance, etc Victor Rentea Consultant, Technical Lead Lead Architect for major IBM client 12 Night Job : Trainer & CoachClean Code Evangelist Speaker victorrentea@gmail.com VictorRentea.ro@victorrentea
- 13. VictorRentea.ro13 Driving Principles –KISS Modeling Data – Enemy data Organizing Logic – Extract when it Grows Clean Architecture – The Onion Tests. Fear. Agenda VictorRentea.ro
- 14. @ VictorRentea.ro Single Responsibility Principle 14 EmployeeManager -read/persist -computepay-roll -generate PDF report -manage projects vs
- 15.
- 16.
- 17. @ VictorRentea.ro Keep It Short& Simple 17 Premature encapsulation is the root of all evilOverengineering – Adam Bien
- 18. @ VictorRentea.ro Premature encapsulation isthe root of all evilOverengineering Keep It Short & Simple 18
- 19. @ VictorRentea.ro Keep It Short& Simple 19 Premature encapsulation is the root of all evilOverengineering Less, simple code Developer Happiness
- 20. @ VictorRentea.ro Invisible Magic toreduce effort and risk Protect the Developers 20 ... Avoid (yet another) Custom Framework (to learn) Developer Comfort
- 21. VictorRentea.ro21 Request/Thread Scope @Autowired private MyRequestContextrequestContext; ... { entity.setModifiedBy(requestContext.getCurrentUser()); } @Component @Scope(value = "request", proxyMode = TARGET_CLASS) class MyRequestContext { ... }
- 22. @ VictorRentea.ro Fear Kills CreativitySimplify Unit Testing - Strong regression defense Protect the Developers 22 Developer Safety
- 23.
- 24. @ VictorRentea.ro24 Today, 7 April2017, I stopped refactoring. Today, my application became Legacy
- 25. @ VictorRentea.ro Transaction Script Procedures workingwith Anemic Entities - Map easily to real-world business procedures Domain Driven Design Rich Entities (OOP) + many XyzServices - Requires deep business involvement - Promises easier maintenance on the long-run - Harder to learn 25 Data Logic Where to implement the domain logic ? or So I separate logic from data
- 26. VictorRentea.ro26 Driving Principles –KISS Modeling Data – Enemy data Organizing Logic – Extract when it Grows Clean Architecture – The Onion Tests. Fear. Agenda VictorRentea.ro
- 27. @ VictorRentea.ro You control them! Entitieshold your persistent data 27 Entity Logic Use them to simplify the implementation of your domain logic
- 28. @ VictorRentea.ro Put small bitsof highly reusable domain logic in your Domain Entities 28 public class Customer { // fields, getters and setters, ... 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.ro Put small bitsof highly reusable domain logic in your Domain Entities 29 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
- 30. @ VictorRentea.ro Entityid Small: Developer Comfort Immutable:Developer Safety Transient: no persistent ID/PK (vs Entity) Value Object: grouping of domain data that move together 30 Logic VOpublic class Money { private Currency currency; private float amount; // ... } public class Money { private Currency currency; private BigDecimal amount; // ... } 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 startbuilding a User Interface (REST, JSF, ...) But you quickly realize UI is your enemy. They want data structures to match the screens. Their goal is different. Never expose your Entities to them. 31 Order.isDeletable:boolean (to show/hide the Delete button)
- 32. @ VictorRentea.ro I personally likethem to be dumb - public fields ?! !!.. Why not? It’s a struct! 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; } } Form/Request View/Response DTO SearchCriteria/SearchResult Data Transfer Objects 32 DTO Instead, give your clients public class CustomerDto { public String fullName; public String phoneNumber; public Date birthDate; } Bare data structures dto.fullName = customer.getFullName(); Why? You’ll see soon…
- 33. VictorRentea.ro33 Driving Principles –KISS Modeling Data – Enemy data Organizing Logic Clean Architecture – The Onion Tests. Fear. Agenda VictorRentea.ro
- 34. @ VictorRentea.ro When DTO Entity conversion is complex or too long Extract Mappers to clean up the domain logic 34 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);
- 35. @ VictorRentea.ro Mappers go toDB ? KISS: Yes ! 35
- 36. @ VictorRentea.ro Mappers go toDB ? KISS: Yes ! 36 public Customer toEntityForCreate(CustomerDto dto) { Customer customer = new Customer(); customer.setBirthDate(dto.birthDate); customer.setGroup(groupRepo.getReference(dto.groupId));... return customer; } public CustomerDto toDto(Customer customer) { CustomerDto dto = new CustomerDto(); dto.birthDate = customer.getBirthDate(); for (Address a:customer.getAddresses()) { for (Address a:addressRepo.getByCustomer(customer.getId())){ ... } return dto; } } Link to DB entities Actually, no DB call Load more data from DB public CustomerDto toDto(Customer customer) { CustomerDto dto = new CustomerDto(); dto.birthDate = customer.getBirthDate(); for (Address a:customer.getAddresses()) { for (Address a:addressRepo.getByCustomer(customer.getId())){ ... } return dto; } … WHERE ADDR.CUSTOMER_ID = ? Lazy-load with ORM Explicit load w/o ORM N+1 Queries
- 37.
- 38. @ VictorRentea.ro Mappers go toDB ? KISS: Yes ! 38 public Customer toEntityForCreate(CustomerDto dto) { Customer customer = new Customer(); customer.setBirthDate(dto.birthDate); customer.setGroup(groupRepo.getReference(dto.groupId));... return customer; } public CustomerDto toDto(Customer customer) { CustomerDto dto = new CustomerDto(); dto.birthDate = customer.getBirthDate(); for (Address a:customer.getAddresses()) { for (Address a:addressRepo.getByCustomer(customer.getId())){ ... } return dto; } } Link to DB entities … WHERE ADDR.CUSTOMER_ID = ? Actually, no DB call Load more data from DB Lazy-load with ORM public CustomerDto toDto(Customer customer) { CustomerDto dto = new CustomerDto(); dto.birthDate = customer.getBirthDate(); for (Address a:customer.getAddresses()) { for (Address a:addressRepo.getByCustomer(customer.getId())){ ... } return dto; } Explicit load w/o ORM
- 39. VictorRentea.ro39 public List<CustomerDto> search(CustomerCriteriacriteria) { List<Customer> customers = customerRepo.search(criteria); return customers.stream() .map(customerMapper::toDto) .collect(toList()); } CLEAN CODE public CustomerDto toDto(Customer customer) { CustomerDto dto = new CustomerDto(); dto.birthDate = customer.getBirthDate(); for (Address a:customer.getAddresses()) { for (Address a:addressRepo.getByCustomer(customer.getId())){ ... } return dto; } N+1 Queries No Prophecies. Simplicity NOW. JPQL: LEFT JOIN FETCH customer.addresses SQL: WHERE ADDR.CUSTOMER_ID IN (?,?,…) (you know the solution)
- 40. VictorRentea.ro40 Measure, Don’t Guess® Prematureencapsulation is the root of all evil – Adam Bien optimization – Donald Knuth Performance ?
- 41. @ VictorRentea.ro Mapper Abused DTOs arereused in different use cases - But some fields are not used in some other cases... Which ones ?!.. 41 public class CustomerDto { public String fullName; public Date birthDate; public Long groupId; public UserTime creation; public UserTime modification; } public class CustomerView extends CustCommDto{ public UserTime creation; public UserTime modification; } public class CustomerCommonDto { public String fullName; public Date birthDate; public Long groupId; } Strict DTOs don’t have useless fields - How to avoid duplication ? DRY public CustomerCommonDto common; - Favor Composition over InheritanceGoF (extends is bad)
- 42. @ VictorRentea.ro You are cheating when’reDRYing code based on a fragile coincidence 42 (on the client side, the data might be interpreted independently)
- 43. @ VictorRentea.ro You are cheating when’reDRYing code based on a fragile coincidence 43 Extract constants to explain the logic Don’t make a constant here
- 44. @ VictorRentea.ro Start implementing domainlogic in a Facade Extract logic into Domain Services - To hide complexity – SRP / KISS - For Reuse (across Facades or Services) - DRY 44 Mapper VOEntityid DTO Fç Façade Domain Service Domain Service Domain Services
- 45. @ VictorRentea.ro Domain Model 45 Mapper VOEntityid Fç FaçadeDomain Service Domain Service speak your Domain Model Keep DTOs out of your logic! Convert them to your Domain DTO Fragile, under enemy control * That’s why I like dumb DTOs Domain Services
- 46. VictorRentea.ro Fç Validate Data Façade Convert Data ImplementLogic Aspects - Transaction - Logging - Global Exception Handling* 46 Facade Roles DTO Validator Mapper Domain Service VOEntityid
- 47. VictorRentea.ro47 What do youmean ? When a class grows too big (>~200 lines?) break it Extract when it Grows How? Look for a good class name to group some of its methods Huh? 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”
- 48.
- 49. @ VictorRentea.ro In L/XL apps:hard to feel opportunities Pair programming, design brainstorming 49 OrderService AlertService DeliveryService Extract for Reuse Separation by Layers of Abstraction Increase the Bus Factor
- 50.
- 51. @ VictorRentea.ro Developer Comfort is essentialfor Emerging Architectures
- 52.
- 53. VictorRentea.ro53 Driving Principles –KISS Modeling Data – Enemy data Organizing Logic – Extract when it Grows Clean Architecture – The Onion Tests. Fear. Agenda VictorRentea.ro
- 54. VictorRentea.ro54 VOEntityid Domain Service Domain Service What code wouldyou protect? Put it in the domain module Priceless Domain Logic Domain Objects
- 55.
- 56.
- 57.
- 58.
- 59. VictorRentea.ro59 public class LDAPUserServiceAdapter{ private LdapContext ctx; ... public LdapUserSearchResult findAccountByAccountName(String ldapSearchBase, String accountName) { try { String searchFilter = "(&(objectClass=user)(sAMAccountName={1}))"; SearchControls searchControls = new SearchControls(); searchControls.setSearchScope(SearchControls.SUBTREE_SCOPE); NamingEnumeration<SearchResult> results = ctx.search( ldapSearchBase, searchFilter, new Object[]{accountName} searchControls); if (!results.hasMoreElements()) return null; } SearchResult searchResult = (SearchResult) results.nextElement(); if (results.hasMoreElements()) { throw new MyAppException(ErrorCode.DUPLICATE_USER_IN_LDAP); } return new LdapUserSearchResult(searchResult); } catch (NamingException e) { throw new MyAppException(ErrorCode.LDAP_LOOKUP_FAILED); } } } External Service Adapter . . . . .
- 60. VictorRentea.ro infra ExtServ Adapter 60 External Service DTO JAXB JSON Protect your Domain Model! Domain Service <dependency> DTOsmight slip in your domain ! domain
- 61.
- 62. VictorRentea.ro low-level modulehigh-level module ExtServ Adapter 62 IExtServ Adapter <dependency> implements atruntime, calls Higher level modules should not depend on lower-level modules class OrderRepository implements IOrderRepo { public Order getById() { ... } } interface IOrderRepo { Order getById(); } Dependency Inversion Principle Domain Serviceclass OrderService { IOrderRepository repo; ...{ repo.getById(id); } } Speaks your Domain Model Spring/CDI/Guice/… will inject it @Autowired Implement it outside
- 63.
- 64.
- 65.
- 66. VictorRentea.ro66 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 (DB access) Priceless Domain Logic Domain Objects
- 67.
- 68.
- 69.
- 70. VictorRentea.ro public Employee getById(StringemployeeId) { String sql = "SELECT id, name, phone FROM employee WHERE id = ?"; Connection conn = null; try { conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, employeeId); ResultSet rs = ps.executeQuery(); if (rs.next()) { Employee employee = new Employee(); employee.setId(rs.getString(1)); employee.setName(rs.getString(2)); employee.setPhone(rs.getString(3)); return employee; } } catch (SQLException e) { // TODO: something, don't know what.. } finally { if (conn != null) { try { conn.close(); } catch (SQLException e) { // TODO: something, don't know what.. } } } return null; } Plain Old JDBC (’90-style) 70 Hide the persistence! Clean your Logic!
- 71. VictorRentea.ro public Employee getById(StringemployeeId) { String sql = "SELECT id, name, phone FROM employee WHERE id = ?"; Connection conn = null; try { conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, employeeId); ResultSet rs = ps.executeQuery(); if (rs.next()) { Employee employee = new Employee(); employee.setId(rs.getString(1)); employee.setName(rs.getString(2)); employee.setPhone(rs.getString(3)); return employee; } } catch (SQLException e) { // TODO: something, don't know what.. } finally { if (conn != null) { try { conn.close(); } catch (SQLException e) { // TODO: something, don't know what.. } } } return null; } Plain Old JDBC (’90-style) public Employee getById(String employeeId) { return jdbcTemplate.queryForObject( "SELECT id, name, phone FROM employee WHERE id = ?", new RowMapper<Employee>() { public Employee mapRow(ResultSet rs, int rowNum) throws SQLException { Employee employee = new Employee(); employee.setId(rs.getString(1)); employee.setName(rs.getString(2)); employee.setPhone(rs.getString(3)); return employee; } }, employeeId); } Spring’ JdbcTemplate (or similar) 71 Hide the persistence! Clean your Logic!
- 72. VictorRentea.ro public Employee getById(StringemployeeId) { String sql = "SELECT id, name, phone FROM employee WHERE id = ?"; Connection conn = null; try { conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, employeeId); ResultSet rs = ps.executeQuery(); if (rs.next()) { Employee employee = new Employee(); employee.setId(rs.getString(1)); employee.setName(rs.getString(2)); employee.setPhone(rs.getString(3)); return employee; } } catch (SQLException e) { // TODO: something, don't know what.. } finally { if (conn != null) { try { conn.close(); } catch (SQLException e) { // TODO: something, don't know what.. } } } return null; } Plain Old JDBC (’90-style) public Employee getById(String employeeId) { return jdbcTemplate.queryForObject( "SELECT id, name, phone FROM employee WHERE id = ?", new RowMapper<Employee>() { public Employee mapRow(ResultSet rs, int rowNum) throws SQLException { Employee employee = new Employee(); employee.setId(rs.getString(1)); employee.setName(rs.getString(2)); employee.setPhone(rs.getString(3)); return employee; } }, employeeId); } Spring’ JdbcTemplate (or similar) public interface IOrderRepository { Employee getEmployeeBasicById(int id); } <select id="getEmployeeBasicById" parameterType="int" resultType="Employee"> SELECT id, name, phone_number AS phoneNumber FROM EMPLOYEES WHERE ID = #{id} </select>MyBatis DataMapper 72 Hide the persistence! Clean your Logic!
- 73. VictorRentea.ro public Employee getById(StringemployeeId) { String sql = "SELECT id, name, phone FROM employee WHERE id = ?"; Connection conn = null; try { conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, employeeId); ResultSet rs = ps.executeQuery(); if (rs.next()) { Employee employee = new Employee(); employee.setId(rs.getString(1)); employee.setName(rs.getString(2)); employee.setPhone(rs.getString(3)); return employee; } } catch (SQLException e) { // TODO: something, don't know what.. } finally { if (conn != null) { try { conn.close(); } catch (SQLException e) { // TODO: something, don't know what.. } } } return null; } Plain Old JDBC (’90-style) public Employee getById(String employeeId) { return jdbcTemplate.queryForObject( "SELECT id, name, phone FROM employee WHERE id = ?", new RowMapper<Employee>() { public Employee mapRow(ResultSet rs, int rowNum) throws SQLException { Employee employee = new Employee(); employee.setId(rs.getString(1)); employee.setName(rs.getString(2)); employee.setPhone(rs.getString(3)); return employee; } }, employeeId); } Spring’ JdbcTemplate (or similar) class IOrderRepository { Employee getEmployeeBasicById(int id); } <select id="getEmployeeBasicById" parameterType="int" resultType="Employee"> SELECT id, name, phone_number AS phoneNumber FROM EMPLOYEES WHERE ID = #{id} </select> MyBatis DataMapper public Employee getById(String id) { List<Employee> list = em.createQuery( "SELECT e from Employee e where e.id=:id", Employee.class) .setParameter("id", id) .getResultList(); if (list.isEmpty()) { return null; } else { return list.get(0); } } JPA/Hibernate 73 Hide the persistence! Clean your Logic!
- 74. VictorRentea.ro public Employee getById(StringemployeeId) { String sql = "SELECT id, name, phone FROM employee WHERE id = ?"; Connection conn = null; try { conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, employeeId); ResultSet rs = ps.executeQuery(); if (rs.next()) { Employee employee = new Employee(); employee.setId(rs.getString(1)); employee.setName(rs.getString(2)); employee.setPhone(rs.getString(3)); return employee; } } catch (SQLException e) { // TODO: something, don't know what.. } finally { if (conn != null) { try { conn.close(); } catch (SQLException e) { // TODO: something, don't know what.. } } } return null; } Plain Old JDBC (’90-style) public Employee getById(String employeeId) { return jdbcTemplate.queryForObject( "SELECT id, name, phone FROM employee WHERE id = ?", new RowMapper<Employee>() { public Employee mapRow(ResultSet rs, int rowNum) throws SQLException { Employee employee = new Employee(); employee.setId(rs.getString(1)); employee.setName(rs.getString(2)); employee.setPhone(rs.getString(3)); return employee; } }, employeeId); } Spring’ JdbcTemplate (or similar) class IOrderRepository { Employee getEmployeeBasicById(int id); } <select id="getEmployeeBasicById" parameterType="int" resultType="Employee"> SELECT id, name, phone_number AS phoneNumber FROM EMPLOYEES WHERE ID = #{id} </select> MyBatis DataMapper public Employee getById(String id) { List<Employee> list = em.createQuery( "SELECT e from Employee e where e.id=:id", Employee.class) .setParameter("id", id) .getResultList(); if (list.isEmpty()) { return null; } else { return list.get(0); } } JPA/Hibernate @Repository public interface EmployeeRepository extends JpaRepository<Employee, Integer>,EmployeeRepositoryCustom { public Employee getById(Integer employeeId); public Optional<Employee> getByName(String name); public Long countByName(String name); @Query("SELECT e FROM Employee e LEFT JOIN FETCH e.projects") public List<Employee> getAllFetchProjects(); } Spring Data JPA - our (fine) selection 74 Hide the persistence! Clean your Logic!
- 75.
- 76.
- 77. VictorRentea.ro77 IRepository Repository implementation it’s a better, Cleaner,Testable world Order Repo implements calls DIP Hide the persistence! Clean your Logic! 1 repo/Entity Split them when they grow domain repo
- 78.
- 79.
- 80. VictorRentea.ro api 80 Façade DTO Validator Mapper VOEntityid Domain Service Domain Service IRepo Repo implem F application infra IExtSrv Adapter ExtSrv Adapter WS Interface DTO IFacade Sent toremote Java clients persisting knowledge…That’s all I got on architectures
- 81. VictorRentea.ro83 Driving Principles –KISS Modeling Data – Enemy data Organizing Logic – Extract when it Grows Clean Architecture – The Onion Tests. Fear. Agenda VictorRentea.ro
- 82. @ VictorRentea.ro Lots of UnitTests are Good ! 84 A sense of confidence Developer Courage Continuous Refactoring (It’s still a single )
- 83. VictorRentea.ro85 As you fightto write Unit Tests, the Production code gets simpler
- 84.
- 85. @ VictorRentea.ro87 First couple ofunit tests – The most valuable Test no. difficulty
- 86. @ VictorRentea.ro Fast tests, Fastfeedback A. Input-output Pure functions, no side effects. Ideally, no dependencies ! B. Domain logic by mocking dependencies Less readable tests C. Queries on a fresh database for each test (in-memory) Reuse complex test data -> Fragile tests ? 88 𝑓 𝑥, 𝑦 = 𝑥2 + 𝑦2 examples JavaScript Unit Tests?
- 87. @ VictorRentea.ro Prod:Test code size 1:3– 1:10 Short, Readable, Clean tests @Test(expected = ValidationException.class) public void withoutNameFails() { validator.validate(aValidCustomer().withName(null).build()); } Write Unit Test is HARD !
- 88.
- 89. @ VictorRentea.ro Disclaimer 91 Experience in Banking, Flavors,ERP and Posting domains Mostly Backend Guy Open-minded Client (Freedom to architecture) Projects of size S-L
- 90. VictorRentea.ro92 Driving Principles – Agenda VictorRentea.ro KISS ModelingData – Organizing Logic – Clean Architecture – Tests. Fear. Extract when it Grows The Onion Enemy data
- 91. VictorRentea.ro93 Driving Principles – VictorRentea.ro KISS ModelingData – Organizing Logic – Clean Architecture – Tests. Fear. Extract when it Grows The Onion Enemy data AgendaTakeaways
- 92. VictorRentea.ro94 VictorRentea.ro Tests. Fear. OrganizingLogic – Extract when it Grows Clean Architecture – The Onion Modeling Data – Enemy data KISS: Avoid overengineering Magic to protect your Developers Takeaways
- 93. VictorRentea.ro95 VictorRentea.ro Tests. Fear. OrganizingLogic – Extract when it Grows Clean Architecture – The Onion Enemy data KISS: Avoid overengineering Magic to protect your Developers in your DTOs: keep them out Takeaways
- 94. VictorRentea.ro96 VictorRentea.ro Tests. Fear. Extractwhen it Grows Clean Architecture – The Onion KISS: Avoid overengineering Magic to protect your Developers : for SRP or DRY Enemy data in your DTOs: keep them out Takeaways
- 95. VictorRentea.ro97 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)
- 96. VictorRentea.ro98 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)
- 97.
- 98.
- 99. 101 How to apply all thisin my legacy code ?? Where can I read more ? Show us more code !! ©
- 100. @ VictorRentea.ro 7 Virtutes ofa 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” Further Reading 102
- 101. @ VictorRentea.ro103 HUGE Thanks to theJPoint Reviewers !! Vladimir Sitnikov Anton Arhipov
- 102. Enterprise Java Training VictorRentea.ro victor.rentea@gmail.com @victorrentea ©Copyright Victor Rentea 2017 Victor Rentea 22 feb 2017 Brainstorming a Clean Pragmatic Architecture