On 13 August 2014 08:17, Peter Inglesby <peter.ingle...@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@python.org https://mail.python.org/mailman/listinfo/python-uk
