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.
Hansel On Wed, Aug 13, 2014 at 11:32 AM, James Broadhead <jamesbroadh...@gmail.com> wrote: > 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 > > -- Hansel
_______________________________________________ python-uk mailing list python-uk@python.org https://mail.python.org/mailman/listinfo/python-uk
