Relentless Refactoring

1,389 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,389
On SlideShare
0
From Embeds
0
Number of Embeds
39
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Relentless Refactoring

  1. 1. Relentless Refactoring Strategic improvement through  Domain-Driven Design Mark Rickerby
  2. 2. @maetl maetl.net github.com/maetl
  3. 3. Introducing the most popular software architecture in the world...
  4. 4. ¶ Big Ball of Mud
  5. 6. The year 2000 in web software <ul><li>Continuum of architectural confusion </li></ul>brutalist structure organic miasma procedural PHP, Perl, ASP, etc... spaghetti code jungle  J2EE framework standards indirection and bloat
  6. 7. The year 2000 in web software <ul><li>Continuum of architectural confusion </li></ul>brutalist structure organic miasma
  7. 8. <ul><li>“ Elegance is not a dispensable luxury but a factor that decides between success and failure.” </li></ul><ul><li>Edsger Dijkstra </li></ul>
  8. 9. Design patterns <ul><li>Eventually developers figured it out </li></ul>
  9. 10. Design patterns <ul><li>An explosion of web frameworks followed </li></ul>
  10. 11. Convention over configuration <ul><li>Generic Model-View-Controller separation </li></ul>app/controllers/CategoriesController.php app/controllers/ProductsController.php app/models/Category.php app/models/Product.php app/templates/categories/* app/templates/products/*
  11. 12. What is the model? <ul><li>Are these data objects or domain objects? </li></ul>app/controllers/CategoriesController.php app/controllers/ProductsController.php app/models/Category.php app/models/Product.php app/templates/categories/* app/templates/products/*
  12. 13. Anemic models <ul><li>The result of leaky abstractions </li></ul>— the app/models convention is a sensible default for basic CMS driven websites —  Active Record fools developers into thinking that persistence is the core concept of the ‘M’ in MVC
  13. 14. Eventual inconsistency <ul><li>If a shortcut exists it will be used </li></ul>— when the software model does not capture rich relationships and behavior, controllers and templates expedite the process of adding new functionality
  14. 15. Eventual inconsistency <ul><li>Framework defaults become inexact </li></ul>app/controllers/CategoriesController.php app/controllers/CheckoutController.php app/controllers/ProductsController.php app/models/Category.php app/models/Product.php app/templates/categories/* app/templates/checkout/* app/templates/products/*
  15. 16. Ad-hoc development <ul><li>When features outgrow the framework </li></ul>— when in doubt, developers add new behavior to existing methods — bug-fixes and knowledge about system behavior accumulates in procedural code
  16. 17. Metaphor shear <ul><li>Loss of cohesion; design disorientation </li></ul>
  17. 18. Ad-hoc duplication <ul><li>Reliance on utility functions for common tasks </li></ul>$units = $config->defaultWeightUnits; $w = explode(' ', $product->weight); if ($w[1] != 'lbs') {     $weight = convertWeight(                 $w[0], $units, 'lbs'               ); } else {     $weight = $w[0]; }  
  18. 19. Ad-hoc behaviour <ul><li>Independent services tangled inside existing interface </li></ul>class Product extends ActiveRecord {   public function create($imported=false) {      if ($imported) {       // edge case when the       // product is created from       // a bulk import     }   }    }
  19. 21. ¶ Domain Driven Design
  20. 22. Domain Driven Design <ul><li>Eric Evans, 2004 </li></ul>really a book about refactoring
  21. 23. Discover missing concepts <ul><li>Refactoring towards deeper insight </li></ul>— focus on conceptual integrity — be prepared to look at things in a different way — constantly refine the language used to describe the software domain
  22. 24. A unified language <ul><li>Not just a collection of singular entities </li></ul>$ mv app/models app/model  
  23. 25. A unified language <ul><li>Building blocks for a fine grained model </li></ul>Entity~  persistent ‘noun’ with identity and state eg: product, category Value~   atomic object with no unique identity eg: price, currency, weight Service~   stateless ‘verb’, action or process Aggregate~   a cluster of related objects
  24. 26. Ad-hoc duplication <ul><li>Reliance on utility functions for common tasks </li></ul>$units = $config->defaultWeightUnits; $w = explode(' ', $product->weight); if ($w[1] != 'lbs') {     $weight = convertWeight(                 $w[0], $units, 'lbs'               ); } else {     $weight = $w[0]; }
  25. 27. Small values  <ul><li>Immutable objects that model basic domain concepts </li></ul>app/model/Product.php app/model/Weight.php $weight = $product->weight->lbs();  
  26. 28. Ad-hoc behaviour <ul><li>Independent services tangled inside existing interface </li></ul>class Product extends ActiveRecord {     public function create($imported=false)     {        if ($imported) {         // edge case when the         // product is created from         // a bulk import       }     }      } 
  27. 29. Service layer <ul><li>Break out standalone tasks into transactional interface </li></ul>class ProductImporter extends BulkImporter {         public function importProduct($product)     {       // no longer an edge case     } }
  28. 30. Aggregate roots <ul><li>Divide complex entities into a more granular model </li></ul>app/model/Attribute.php app/model/AttributeValue.php app/model/Product.php app/model/ProductAttribute.php app/model/ProductDetails.php app/model/Sku.php class Product extends Aggregate {}
  29. 31. Benefits of a richer model <ul><li>Why use object oriented design anyway? </li></ul>— easier to localize changes when behavior and data are close together — negotiate complexity with precise language — objects have a single responsibility; easier to understand and maintain
  30. 32. Design is continuous <ul><li>Change code based on improved understanding </li></ul>— models are dynamic; always changing and growing — models are explanatory; define domain knowledge in code
  31. 33. Ambiguities <ul><li>Contradictory concepts in the domain language </li></ul>— avoid trying to build a monolithic model that captures every aspect of the domain — tackle ambiguity by grouping the model into  Bounded Contexts
  32. 34. Model namespace <ul><li>Grouping based on pattern types </li></ul>app/model/ collections /ProductList.php app/model/ entities /Product.php app/model/ services /ShippingProvider.php app/model/ services /TaxRate.php app/model/ values /Weight.php app/model/ values /Price.php  
  33. 35. Model namespace <ul><li>Grouping based on context boundaries </li></ul>app/model/ Invoicing /TaxRate.php app/model/ Shipping /Provider.php app/model/ Storefront /Price.php app/model/ Storefront /Product.php app/model/ Storefront /ProductList.php app/model/ Storefront /Weight.php  
  34. 36. Shared core <ul><li>Extract common behaviour into a shared context </li></ul>app/model/Core/Price.php app/model/Core/Weight.php app/model/Core/Product.php app/model/Invoicing/TaxRate.php app/model/Shipping/Provider.php app/model/Storefront/ProductList.php
  35. 37. Context map <ul><li>Define relationships between bounded contexts </li></ul>
  36. 38. Homonyms <ul><li>Overloaded concepts in the domain language </li></ul>— the same word is used to describe many different concepts — the same concept has many different responsibilities
  37. 39. Bounded contexts <ul><li>Allow ambiguous concepts to co-exist </li></ul>app/model/Core/Price.php app/model/Core/Weight.php app/model/Core/Product.php app/model/Invoicing/TaxRate.php app/model/Shipping/Product.php app/model/Shipping/Provider.php app/model/Storefront/Product.php app/model/Storefront/ProductList.php
  38. 40. Anticorruption layer <ul><li>Isolating adapter between incompatible contexts </li></ul>
  39. 41. Refactoring is design <ul><li>Changing the structure of existing code </li></ul>
  40. 42. Refactoring is design <ul><li>Changing the structure of component boundaries </li></ul>
  41. 43. Application boundaries <ul><li>Refactoring patterns for evolving architecture </li></ul>Introduce Strangler~ new abstraction that overtakes the host system like a strangling vine Extract Service~ spawn a separate application by extracting a service from the original system
  42. 44. Summary <ul><li>Relentless improvement </li></ul>Separate infrastructure from the model Use precise language to define domain concepts Model complex behaviour in bounded contexts
  43. 45. Thanks Mark Rickerby, 2011

×