Why you shouldnt use django for that
Download as PPTX, PDF4 likes502 views
The document discusses the architectural limitations of Django, emphasizing that it is a tool rather than an architectural framework. It explores concepts such as business logic patterns, including transaction script, table module, and domain model, while highlighting the drawbacks of the anemic domain model and overly reliant CRUD patterns. Ultimately, it contrasts connected systems with modular designs in terms of feature implementation costs and encourages the consideration of architecture beyond the tools used.
Why you shouldnt use django for that
- 1. Why you shouldn’t use Django for that
- 2. Architecture, the lost years Robert C. Martin
- 3. “Web” is not an architecture.
- 5. Django is a tool, not architecture.
- 6. WAIT! What does this even mean?
- 8. Application metaphor, the three layers 1 32
- 9. 1.Interact with the user, both ways 1 32
- 10. 3. Interact with outside world, other systems 1 32
- 11. 2. The code that justifies the app existence 1 32
- 12. Are these layers equally important?
- 13. Do we build them the same way?
- 14. Do these change at the same pace?
- 15. It is all about CHANGE
- 16. OK How does business logic look like?
- 18. Transaction Script Modeled as procedures + Easiest to understand. + Obvious transaction boundaries. - Difficult to de-duplicate.
- 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. 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. 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. Which pattern should I use?
- 23. Which one should we use? Efforttoenhance Complexity of the business logic
- 24. Which one should we use? Efforttoenhance Complexity of the business logic 7.42
- 25. Which pattern does Django follow?
- 27. Anemic Domain Model - Objects have state, but no behavior - The Business is somewhere else Leads to: - Upside down Transaction Script - God objects
- 28. Anemic Domain Model - Objects have state, but no behavior - The Business is somewhere else Leads to: - Upside down Transaction Script - God objects
- 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. 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
- 37. 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
- 39. WAIT! OK, Active Record is bad, but what about productivity?
- 40. Django vs. OOP
- 41. Django vs. OOP Is not the debate here
- 42. Questions? Or come and ask me later!
- 43. Thank you! Oh, and we are hiring! @istepaniuk
Editor's Notes
- #2: Confession: The title is a bit of trick. We are going to speak about application architecture.
- #3: 2013 Norwegian Developers Conference - (and Javier Acero excellent talk in Madrid) How the web changed the way we write software In the first “WEB” decade, we forgot a lot about architecture. Smart people retire.
- #4: The web is ONE transmission channel, is how you deliver, it's a detail. That's all. If PostNL changes to UPS - your business keeps running.
- #5: Frameworks are tools, they can't be in the center of the architecture. Architecture is more about DEFERRING decisions than to decide. Frameworks should too, be a detail.
- #6: So Django CAN'T be the center of your application. Most importantly, architecture-wise: The way we write applications in Django is -NOT- a generally correct way to write an application
- #7: WTF does this mean? What do you mean by application architecture then? Let's think through this!
- #8: I work at the cloakroom as a backend developer, we use python (and even some django)
- #9: The classic 3 layers. Deliberately, not going to try to name all three now
- #10: Producing HTML JSON, An HTTP API, REST Command Line Desktop or Mobile UI widgets
- #11: Databases and Message Queues Sending an email The file system
- #12: Validation, Calculation Calls to external systems (or preferably to abstractions) IE: Calculate taxes, add invoice lines, etc. This is the Business logic.
- #13: What is it more important? that a form looks nice, it's usability? that the persistence is really fast? or... that taxes to be calculated correctly?
- #14: NO WE DON’T! The Busines Logic layer is more difficult to reuse between different problem domains. It is specific. Layer 3, ...we generally do not write DB drivers, or SMTP clients, etc.
- #15: .
- #16: Do these layers change at the same pace? 1: Technology changes, a decade ago no JS on the front. 3: We now have NoSQL stores, many of them. 2: BL: Domain rules change slowly, length of a credit-card or the age of a person.
- #17: What is Business Logic anyway?
- #18: This influential book from 2003 You wanna read it if you haven’t Mentions the patterns we are going to discuss
- #19: Modeled as procedures (and of course sub-routines), Easy to understand Obvious transaction boundaries. Even extracting subroutines, is difficult to de-duplicate. (in turn more nasty consequences)
- #20: Perhaps more exotic now. One instance for each type object, only one, operates over database rows NO oo-db impedance mismatch No polymorphism, no dynamic linking, nada. Modeling around the database structure
- #21: Specifically based in the domain of the business you are working with (Vaughn Vernon IDDD) Business Logic modeled as object behavior, no DB, no transaction scripts. Business as object graphs and object clusters. The OOP way of modeling. ...
- #22: Real OOP, with all the bells and whistles. + Heuristics like SOLID Hardest to comprehend. Using a domain model is the essence of the paradigm shift to OOP. Code overhead for simple BL. RELATIONAL Data sources get more complex
- #23: .
- #24: this is in PATTERNS - ENTERPRISE - APPLICATION - ARCHITECTURE
- #25: Complexity bigger than 7.42 Impossible to calculate Difficult to predict
- #26: So... What is django pattern?? HOW MANY - Tx Script, Table Mod, Domain Model I'd say. Probably a -some sort of- domain model
- #27: So assuming that, let's take a look at some ANTIPATTERNS
- #28: This is a CLASSIC in many Django apps I’ve seen. Objects have state but no behavior (and Getters+Setters are not behavior) They are just data structures. This is not OOP. Business Logic and thus behavior is somewhere ELSE (controllers,"service" layer, “managers”, forms) Some say call this the "J2EE smell" - NOT TRUE
- #29: This is like Transaction Script, old school CGI Solve it by a "Push it down" refactor, not a design pattern (though it's better) Not really a Domain model. just a twisted Transaction Script God objects (User + The most application centric object; Product)
- #30: God objects can be solved with mixins PYTHON has it.
- #31: Mixings are inheritance. Inheritance is the strongest form of coupling, you are just spreading the code. You are only making things worse Prefer composition.
- #32: Viscosity due to tight coupling, persistence and logic coupled together, you can’t change ANY Complex tests need database to run or complex sorcery. Test behavior, not implementation. CRUD obsession >>>>
- #33: Difficult to avoid in Django: The domain model is basically the data model All objects backed up by a table. Databases are part of the 3rd Layer, DETAILS they do not belong to the DM. They have design requirements Leads to ...
- #34: You may think that it means… BUT. Actually stands for
- #35: C, R, U, D are consequences of the use cases, not THE use cases.
- #36: CRUD APPs are LEGACY We are not modeling the paper-based office in software anymore
- #37: There is an APP for that!
- #38: Lastly
- #39: This antipattern is Unavoidable in Django (and any other ActiveRecord based framework) Global state, models are omnipresent (accessible even from the templates through lazy loading). No real separation, the three layers are connected and tightly coupled. They can't easily change at different pace. Active Record is the culprit. AGAIN
- #40: The “Django way” is FAST, but consider it is a HUGE trade-off, specially for complex apps. Are you prepared to pay the price? BUT it works for me! - Maybe, but at least keep all these things in mind.
- #41: So Django vs. OOP is ….
- #42: NOT THE DEBATE Frameworks are tools, and they have a place. Django is probably good enough if CRUD is good enough for your application - (which rarely is). Where I say Django, you can say Rails, Spring, and other paternalistic, Active Record based frameworks.
- #43: If we still have time
- #44: HIRING!