[python-uk] hexagonal Django

[Peter Inglesby]

> I'm starting my week-long exercise on trying it out on a slice of our
existing Django monster. I'll report back.

Echoes of Captain Oates here?

Anyway, reviving an old thread: Brandon Rhodes talks provides a
straightforward and accessible summary of "The Clean Architecture" in a
recent talk[0] and it's the least wanky discussion of this kind that I've
come across.  His main point is that things with side effects (particularly
calling external services) should be isolated in "procedural glue" code,
while the processing of data -- the business logic -- should happen in pure
functional code.  This leads to a better focus on the structure of the data
you're dealing with, which in turn leads to more comprehensible and
maintainable code.

Thoughts?

[0] http://www.pyvideo.org/video/2840/the-clean-architecture-in-python


On 13 December 2012 11:28, Jonathan Hartley <tartley at tartley.com> wrote:

> Thanks everyone. I've been enlightened, encouraged and forewarned by the
> responses to my initial question. (and thanks for the Rich Hickey talk, I
> hadn't seen that one)
>
> I absolutely empathise with the warnings to avoid needlessly creating
> extra layers or plumbing.
>
> I have a colleague who says many of the projects where he used to work at
> Microsoft Research used this pattern, and while he liked it overall, if he
> had to find fault, they found it to cause duplication of sorts, in things
> like the persistence component mapping fields of the business objects into
> database-compatible types. Hence adding a field meant both changing the
> core business object, and changing the persistence component to incorporate
> the extra field, and also the plumbing between the two.
>
> I also heed the advice to beware shoehorning problems into a single
> one-size-fits-all solution.
>
> I also liked people who brought up particular thorny areas with Django in
> particular, such as the admin views.
>
> However, I'm hopeful that, in my particular case at least, the interfaces
> and extra layers will be close to trivial, and any disadvantages may be
> outweighed by extracting my database/network code from my business logic.
>
> I'm starting my week-long exercise on trying it out on a slice of our
> existing Django monster. I'll report back.
>
>     Jonathan
>
>
>
>
> On 10/12/2012 19:02, Chris Withers wrote:
>
>> 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
>>> ______________________________________________________________________
>>>
>>
>>
> --
> Jonathan Hartley    tartley at tartley.com    http://tartley.com
> Made of meat.       +44 7737 062 225       twitter/skype: tartley
>
> _______________________________________________
> python-uk mailing list
> python-uk at python.org
> http://mail.python.org/mailman/listinfo/python-uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-uk/attachments/20140813/fc40a0fc/attachment.html>