115K views · Aug 9, 2014 · 49:54 · 5 HN recommenders · 7 mentions · discussed 2017–2021
Brandon Rhodes' PyOhio 2014 talk on applying the Clean Architecture in Python. He shows how this high-level design pattern fits Python's features and addresses maintainability problems in large applications.
Why Hacker News points people here: HN points to it as a practical way to separate business logic from I/O, which reduces mocking and underlies the functional core, imperative shell idea.
“I'd really recommend this video.”HN comment, 2021
“I'd really recommend this video.”
Changing architecture changes how you need mocks.
I'd really recommend this video. I had seen it years ago and just came back to it. It's about changing your architecture, one of the effects of that being changing how you need/use mock. this video
“there is also a better explanation of the same concept by Brandon Rhodes: The Clean Architecture in Python.”
Better explanation of clean architecture for Python programmers.
For the Python programmers, there is also a better explanation of the same concept by Brandon Rhodes: The Clean Architecture in Python. this video
“in general I like Brandon Rhodes' PyCon talks”
Brandon Rhodes talk on layered architecture ideas.
I was going to write that I don't have a good pointer, but actually I think the idea is basically the "onion architecture" or "clean architecture". I don't recall if I watched all of this talk, but in general I like Brandon Rhodes' PyCon talks : this video link I don't come from a Java background, but I think that many of these ideas originated in the Java community. They came to Python later (if at all), and it's a little funny to see Go struggling with the same thing. I think I came at it from more of a functional programming perspective, and the style gradually converged with what people were thinking about OOP. I'm not actually of all the details about "clean architecture" and "onion architecture", but they are definitely related to dependency injection. Basically all your effects and state can be instantiated on the "outside" in main() and passed INWARD. But I don't believe it necessarily has to be pure. I encapsulate all my state, but I don't encapsulate all my side effects, like printing to the screen. Some people appeared to like this comment, which is somewhat related: link I'm not sure how much this will help, but here is 12K+ lines of code I wrote with zero globals: link The main directories to look at are core/ and osh/. The main program imports a lot of stuff and wires it together: link (There is a bunch of surface messiness, but the architecture is sound.) I've also written even larger programs with zero globals. Also, I believe that web frameworks are some
“I like how Brandon Rhodes explain how to apply it in Python”
Shows how to apply functional core, imperative shell in Python.
This is the same principle of the Clean Architecture. I like how Brandon Rhodes explain how to apply it in Python: this video
“These are some of my favorites”
Listed among favorite Python talks.
These are some of my favorites: Clean Architectures in python: this video Pandas from ground up: link How to write actually object-oriented python: link It's Time to Learn Regular Expressions: link
“is the actionably good thing i've taken from Brandon Rhoades' talk based on this”
Talk's key idea is pushing I/O out to the edges.
"Promote I/O to management (where it can't do any damage)" is the actionably good thing i've taken from Brandon Rhoades' talk based on this: this video Living in a world where people regularly write single functions that: 1. loads data from a hardcoded string path of file location 2. does all the analysis inside the same loop that the file content iteration happens in and 3. plots the results ... that cleavage plane is a meaningfully good one. The rest of the ideas fall into "all things in moderation, including moderation", and can and should be special-cased judiciously as long as you know what you're doing. But oh god please can we stop writing _that_ function already.
“Some resources to further explore these ideas”
Resource on separating business logic from IO to reduce mocking.
I have been researching into several testing approaches and so far in my experience yes fakes are better than mocks. But what is even better is not having to fake or mock stuff especially for testing business logic. One of the problems we get ourselves into is abstracting service io code into functions and calling them from our business logic code. This forces us to mock all the io calls, instead we should be doing the opposite i.e abstracting business logic into discrete functions of pure data in and out and then calling those functions from our io code. This way we can test the business logic independently of the io code. Testing the business logic now becomes quite simple and one can leverage property testing to further boost our confidence in such tests. Many times the ramaining io code is just calling other functions and doesn't need to be tested. Several other ideas that relate to this are hexagonal architecture, Domain Driver Design, clean architecture and functional core with an imperative shell. Some resources to further explore these ideas: Clean Architecture in Python - this video Why integrated tests are a scam - link Boundaries - link
