[python-uk] hexagonal Django

[Jonathan Hartley]

Thanks for the Brandon talk link: I hadn't seen it yet and I'm eager to 
see anything new from him.

 > Oates

I did embark on the Django refactor, and in my mind it was a success of 
sorts. Obviously we didn't derive any immediate business value from that 
refactor, but it did demonstrate that the approach was viable, and I 
liked the way that the code turned out. I would seriously consider it on 
future projects (I'm not doing Django at the moment, and my current 
project has a large codebase that I'm not going to try to re-architect.)

There were some sticking points that with hindsight seemed predictable. 
I don't know that I can remember them specifically now, but the pattern 
seemed to be that it would have been much easier if our code had kept 
Django at a bit more of arms-length, rather than wholeheartedly relying 
on it for *everything*.

For example, we had used things like Django's magic 'settings' module to 
store all sorts of project-wide constants. This caused problems for the 
'clean architecture' approach, because it meant that any code which 
wanted to access any settings needed to import the Django settings 
mechanism. Better, instead, to use Django's settings module to just 
store Django configuration options, and store project-wide constants in 
more generic place of your own devising.

So, as advertised, it seemed that the 'clean' approach really did make 
it more visible when we weren't being very smart about managing our 
dependencies, and force us to limit them more than we previously had.

     Jonathan


On 13/08/14 11:32, James Broadhead wrote:
> On 13 August 2014 08:17, Peter Inglesby <peter.inglesby at gmail.com> wrote:
>
>>> 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
>>
> I'm always reminded of that Rimmer quote about Oates...
>
> I've been doing this recently with Twisted -- separating out async code
> that deals with deferred chains from synchronous logic handling the results
> of the deferreds.
> I'm finding that it's leading to clear, easily tested code -- simple
> synchronous tests on real data for the business logic, and stubbed
> success/failures to test the various code-paths in the deferred logic.
> I came to this variously by tangling too much with mixes of deferred-flows
> and business logic while trying to write simple tests and seeing this DAS
> talk on Boundaries [1]
>
> d = defer.succeed(foo)
> d.addCallback(handle_foo)
> d.addCallback(make_request)
> d.addErrback(retry, make_request, foo)
> d.addCallback(parse_body)
> return d
> ^ code like this is easily tested by stubbing all the callbacks, with the
> stubs either succeeding or raising synchronous exceptions.
>
> def parse_body(body):
>    content = json.parse(body.read())
>    if not 'username' in content:
>      raise HttpError(401)
>    return Response(content)
> ^ again, really easy to test. No deep nested logic, no need to mock or
> stub.
>
> [1] https://www.destroyallsoftware.com/talks/boundaries
>
>
>
> _______________________________________________
> python-uk mailing list
> python-uk at python.org
> https://mail.python.org/mailman/listinfo/python-uk

-- 
Jonathan Hartley    tartley at tartley.com    http://tartley.com
Made of meat.       +44 7737 062 225       twitter/skype: tartley

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-uk/attachments/20140813/eb27453d/attachment-0001.html>