O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Hexagonal Symfony - SymfonyCon Amsterdam 2019

1.059 visualizações

Publicada em

https://matthiasnoback.nl/

Publicada em: Software
  • Seja o primeiro a comentar

Hexagonal Symfony - SymfonyCon Amsterdam 2019

  1. 1. Hexagonal Architecture with Symfony @matthiasnoback info@matthiasnoback.nl Slides are onTwitter
  2. 2. Somebody's wrong on the internet
  3. 3. Somebody's wrong on the internet
  4. 4. I'm one of them
  5. 5. This is not to say that we shouldn't listen to any advice!
  6. 6. Where does advice come from?
  7. 7. Experience ● You look back on a recent project that went well ● You look at your choices and consider them the cause of the project's success ● You tell other people to make the same choices.
  8. 8. People will copy your choices
  9. 9. They fail
  10. 10. "They got it all wrong, just do this!"
  11. 11. Don't follow anyone
  12. 12. Listen to your code Listen to its design Easy to move? Easy to test? Easy to add a constructor argument? Easy to rename?
  13. 13. Collect and share heuristics
  14. 14. Heuristics?
  15. 15. What worked well In which situation And what's a good rule of thumb for it
  16. 16. Should you... Use façades? Use Yaml? Write methods you can call with 0, 1 or 2 arguments? Use middlewares? Use PSR-7? Over-engineer your project using hexagonal architecture?
  17. 17. Write about what your experience
  18. 18. Change is really hard for most software projects I've encountered
  19. 19. Reasons for change Framework integration code
  20. 20. Reasons for change Remote service calls
  21. 21. Reasons for change Domain model
  22. 22. Single responsibility principle for architecture What changes for the same reason should be grouped together
  23. 23. Examples ● All the things related to your framework ● All the things related to your domain model ● All the things related to your database ● ...
  24. 24. The most important distinction is... Not too many groups
  25. 25. Domain vs Infrastructure ● Model (entities, value objects) ● Use cases (application services) ● Interfaces for boundary objects ● Framework-specific code ● Implementations for boundary objects ● Web controllers, CLI controllers, etc.
  26. 26. Step 1 Introduce layers
  27. 27. Step 1: Introduce layers Web framework Domain logic Database integration
  28. 28. Introduce layers Web framework Domain logic Database integration InfrastructureDomain
  29. 29. Step 2 Define ports and adapters (Hexagonal architecture; Alistair Cockburn)
  30. 30. Determine actors Application Primary actor: User Secondary actor: Database Primary actor: User Secondary actor: Remote webservice Primary actor: Cronjob
  31. 31. Make a distinction... Between the intention for communication, and the supporting implementation
  32. 32. Examples The user can buy a ticket
  33. 33. Examples We have a TicketsController with a buyTicket action. It gets the logged in user from the session and gets the user's address from the submitted form data.
  34. 34. Examples We need to persist an order
  35. 35. Examples We store order data in an orders table in our MySQL database. We use Doctrine DBAL to talk with that database.
  36. 36. Ports Buyaticket Persistanorder
  37. 37. Adapters Buyaticket Persistanorder HTTPadapter SQLadapter
  38. 38. Advantages By separating domain from infrastructure code you automatically increase testablity
  39. 39. Advantages You can replace an adapter without affecting the ports
  40. 40. Advantages You can postpone the choice for database vendor, framework, ORM, etc.
  41. 41. Advantages You can more easily keep up with the change rate of framework-specific code
  42. 42. Advantages Or replace the framework altogether...
  43. 43. Sources ● Alistair in the "Hexagone": https://www.youtube.com/watch?v=th4AgBcrEHA ● My upcoming book "Advanced Web Application Architecture" https://leanpub.com/web-application-architecture/ ● Nat Pryce, Steve Freeman - Growing Object-Oriented Software, Guided by Tests ● Vaughn Vernon - Implementing Domain-Driven Design (see the chapter about Architecture)
  44. 44. Questions?
  45. 45. Thank you! @matthiasnoback info@matthiasnoback.nl

×