Session: Pure Data and a Clean Architecture

What does the type of your function arguments and return values have to do with software architecture? Are we practicing the wrong kind of ‘complexity hiding’ when we push the ‘dirty’ specifics of our operations down into subroutines, and so interleave the ‘what’ with the ‘how’? Have you ever wondered why you had to use fake- or mock objects or jump through all kinds of hoops to write unit tests even for small pieces of code? The Clean Architecture, a term coined by Robert “Uncle Bob” Martin, is one way to separate the business rules (policies) at the core of an application from the specifics (mechanisms) at its outset (the database, the network, storage systems, etc.). At the interface of those layers, mostly primitive data structures are passed on. Keeping this structure in mind when designing an application or library, will lead to a less coupled, more flexible end product. Scientific and other complex workflows involving distributed computation can benefit from such a conscious layering. The approach greatly improves your code's testability and maintainability. These qualities are especially relevant in scientific software, but often rank low in priority in scientists' coding education and every day execution. Python makes it easy to adopt this style, due to Python’s dynamic nature, very well thought-out built in data structures and a culture of what is considered ‘pythonic’.