Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Why you shouldnt use django for that

We discuss application architecture patterns, anti-patterns and try to position django in this canvas. We step back to see how software design evolved since the advent of the web to better understand where do we stand now.

  • Sé el primero en comentar

Why you shouldnt use django for that

  1. 1. Why you shouldn’t use Django for that
  2. 2. Architecture, the lost years Robert C. Martin
  3. 3. “Web” is not an architecture.
  4. 4. Frameworks are not architecture.
  5. 5. Django is a tool, not architecture.
  6. 6. WAIT! What does this even mean?
  7. 7. Ivan Stepaniuk @istepaniuk
  8. 8. Application metaphor, the three layers 1 32
  9. 9. 1.Interact with the user, both ways 1 32
  10. 10. 3. Interact with outside world, other systems 1 32
  11. 11. 2. The code that justifies the app existence 1 32
  12. 12. Are these layers equally important?
  13. 13. Do we build them the same way?
  14. 14. Do these change at the same pace?
  15. 15. It is all about CHANGE
  16. 16. OK How does business logic look like?
  17. 17. Patterns Enterprise Application Architecture Martin Fowler
  18. 18. Transaction Script Modeled as procedures + Easiest to understand. + Obvious transaction boundaries. - Difficult to de-duplicate.
  19. 19. Table Module Modeled as objects and Record Sets + No DB vs. OO impedance mismatch. - Model is database-centric. - Objects, but not really OO.
  20. 20. Domain Model Modeled after the business you work with. + Real OOP, with all the OO advantages. - Hardest to comprehend and switch to. - Code overhead for simple logic.
  21. 21. Domain Model Modeled after the business you work with. + Real OOP, with all the OO advantages. - Hardest to comprehend and switch to. - Code overhead for simple logic.
  22. 22. Which pattern should I use?
  23. 23. Which one should we use? Efforttoenhance Complexity of the business logic
  24. 24. Which one should we use? Efforttoenhance Complexity of the business logic 7.42
  25. 25. Which pattern does Django follow?
  26. 26. Domain Model Architecture Antipatterns
  27. 27. Anemic Domain Model - Objects have state, but no behavior - The Business is somewhere else Leads to: - Upside down Transaction Script - God objects
  28. 28. Anemic Domain Model - Objects have state, but no behavior - The Business is somewhere else Leads to: - Upside down Transaction Script - God objects
  29. 29. Mixins! To inject concerns
  30. 30. Table Driven Domain Model - The data model is the domain model - All objects backed up by a table Leads to: - High viscosity - Complex, slow, fragile tests - CRUD obsession
  31. 31. Table Driven Domain Model - The data model is the domain model - All objects backed up by a table Leads to: - High viscosity - Complex, slow, fragile tests - CRUD obsession
  32. 32. CREATE READ UPDATE DELETE
  33. 33. DATABASE DATABASE DATABASE DATABASE
  34. 34. Connected Domain Model In a connected system, elements are highly available to each other. Adding the first feature to a connected system is cheap … … the cost of all those connections is that subsequent features are very likely to interact with previous features, driving up the the cost … In a modular design, connections are deliberately kept to a minimum. The cost of the first feature is likely to be higher … Features are less likely to interact in a modular system, though, leading to a steady stream of features at relatively constant cost. - Kent Beck
  35. 35. Connected Domain Model
  36. 36. WAIT! OK, Active Record is bad, but what about productivity?
  37. 37. Django vs. OOP
  38. 38. Django vs. OOP Is not the debate here
  39. 39. Questions? Or come and ask me later!
  40. 40. Thank you! Oh, and we are hiring! @istepaniuk

×