[python-uk] hexagonal Django

Hansel Dunlop hansel at interpretthis.org
Wed Aug 13 13:15:09 CEST 2014

The Brandon Rhodes talk sounds like a nice way of looking at the problem.
What I've done with my latest BIG DJANGO APP is to put the business logic
into a pure Python module,  Which Django imports, initialises with a
storage adaptor (which makes mocking this adaptor easy) and then uses. The
storage adaptor gives the module only Python primitives and the module only
returns Python primitives. Which Django can then do whatever it wants with.
Mostly creating http responses, but also putting them into Celery queues
and the like. It's still a bit messy, but it's very testable.


On Wed, Aug 13, 2014 at 11:32 AM, James Broadhead <jamesbroadhead at gmail.com>

> 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


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

More information about the python-uk mailing list