[python-uk] hexagonal Django
tartley at tartley.com
Wed Aug 13 13:54:17 CEST 2014
Thanks for the Brandon talk link: I hadn't seen it yet and I'm eager to
see anything new from him.
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.
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 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.
>>  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 
> d = defer.succeed(foo)
> d.addErrback(retry, make_request, foo)
> 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
>  https://www.destroyallsoftware.com/talks/boundaries
> python-uk mailing list
> python-uk at python.org
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...
More information about the python-uk