[python-uk] hexagonal Django

Chris Withers chris at python.org
Mon Dec 10 20:02:17 CET 2012


Yeah, what he said :-)

(joking aside, John has summed this all up very nicely...)

Chris

On 06/12/2012 00:57, John Lee wrote:
> 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):
>
> http://www.infoq.com/presentations/Simple-Made-Easy
>
>
> (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.
>
>
> John
> _______________________________________________
> python-uk mailing list
> python-uk at python.org
> http://mail.python.org/mailman/listinfo/python-uk
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk


More information about the python-uk mailing list