[python-uk] hexagonal Django

John Lee jjl at pobox.com
Thu Dec 6 01:57:51 CET 2012

On Tue, 4 Dec 2012, Jonathan Hartley wrote:

> The last few weeks I've been thinking about the architectural pattern known 
> as Clean, Onion, Hexagonal, or Ports'n'Adaptors 
> <http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html> 
> (http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html). 
> I'm curious if many people are applying it in the Django world?
> I haven't, yet, but I'm thinking of refactoring a vertical slice of our 
> monster Django app into this style, and I'd love to hear if you think it's 
> crazy / brilliant / obvious / old-hat, etc.

I have to confess I've only very lightly skimmed the article (which looks 
like it says some sensible things), but that's not going to stop me 
pontificating in over-general terms and posting a video that I liked:

The best programmers I've worked with have a knack to ruthlessly pick the 
simplest possible abstractions to fit the job in hand.  They never stop 
thinking to settle on any one-size-fits-all programming style.  The 
problem with those two statements I just made is that everybody can read 
them and think that they agree with them.  What *I* mean by simple is 
close to what Rich Hickey means in the first part of this talk (though I 
don't know enough to decide what I think about how he goes on to defend 
Clojure and its design principles in those terms):


(BTW, it's a shame to hear him give security as an example of a separable 
concern, because it isn't one)

The best code, you look at the functionality, then the code, and think 
"where is all the code?" and "how did such simplistic code happen to 
implement exactly what was needed?".  That's different from the "OMG, what 
is all this stuff for" feeling you get from over-engineered or just 
badly-factored code.  The best code is easy to change in the sense that 
changes in functionality require commensurate coding effort, and it's 
clear what code would have to change.  But it is also hard to change, in 
the sense that any change that leaves the behaviour the same would clearly 
make it worse -- including adding or removing abstraction.

I'd agree with Andy that not fighting too many battles with your framework 
has a lot to be said for it (and that it's maybe more important to nail 
basic coding practices of the kind you'd find in Code Complete than to 
take even a single step away from what the django tutorial tells you to 
do).  But even short programs can gain simplicity from ignoring the 
framework or abstracting it a little, where it suits the problem, as it 
often does.


More information about the python-uk mailing list