The Clean Architecture in Python

For the Python programmers, there is also a better explanation of the same concept by Brandon Rhodes: The Clean Architecture in Python. [VIDEO]

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 : [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

This is the same principle of the Clean Architecture. I like how Brandon Rhodes explain how to apply it in Python: [VIDEO]

These are some of my favorites: Clean Architectures in python: [VIDEO] Pandas from ground up: [LINK] How to write actually object-oriented python: [LINK] It's Time to Learn Regular Expressions: [LINK]

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 - [VIDEO] Why integrated tests are a scam - [LINK] Boundaries - [LINK]

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. [VIDEO]

"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: [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.