[python-uk] hexagonal Django

[Jonathan Hartley]

On 05/12/2012 13:08, Michael Foord wrote:
> On 5 Dec 2012, at 07:33, Chris Withers <chris at python.org> wrote:
>
>> On 04/12/2012 17:46, Menno Smits wrote:
>>> On 2012-12-04 14:46, Jonathan Hartley wrote:
>>>
>>>> I haven't, yet, but I'm thinking of refactoring a vertical slice of our
>>>> monster Django app into this style, and I'd love to hear if you think
>>>> it's crazy / brilliant / obvious / old-hat, etc.
>>> Since you mentioned this a few weeks back, I've been thinking about this
>>> approach a lot and doing a fair bit of background reading on the idea. I
>>> think it falls in to the brilliantly-obvious category, at least for any
>>> app of significant size. I plan to start using these ideas for my next
>>> big work project (not Django however). Previously, I've tended towards
>>> less flexible, harder-to-test, layered architectures.
>> The biggest concern I have with this approach is that it appears to preclude taking advantage of any features of your storage layer. If your business objects have to not know or care about their underlying storage, how do you take advantage of nice relational queries, stand alone text indexing service or other specific features of the architecture you've chosen?
> I guess you still need to provide an abstraction for these features, even if only one backend supports the abstraction.
What I'm reading suggests that if, for example, your app needs to use a 
text indexing service, then that's an external system and your 
application core should define an API which it will use to talk to it. 
So you still get to use features like this, but you are obliged to put 
an API layer (and possible inversion of control) between them, rather 
than making the call directly from within your business logic.

Similarly, if your business logic needs a small number of particular 
relational-type queries, then perhaps those queries should be the API 
defined by your core for talking to persistence. If your app needs many 
such queries, or general-purpose relational querying support, then 
perhaps you can create an API which supports general purpose querying 
such as the 'repository' pattern.

I'm no expert. The above is my newfound understanding and some speculation.

>> There's also the risk that you end up testing each bit (business, views, storage) in isolation and never get around to doing the automated integration testing required to ensure artifacts of implementation (*cough* bugs) don't cause problems across those boundaries...
> Well, you need integration / acceptance / functional / end to end tests *anyway*.
>
> Michael
>
>> That said, I'd love to see a project that's a good example of this, are there any around online in Python? The closest thing I can think of is the move to the component architecture that Zope did from v2 to v3; architecturally brilliant but actually killed off the platform...
>>
>> cheers,
>>
>> Chris
>>
>> -- 
>> Simplistix - Content Management, Batch Processing & Python Consulting
>>             - http://www.simplistix.co.uk
>> _______________________________________________
>> python-uk mailing list
>> python-uk at python.org
>> http://mail.python.org/mailman/listinfo/python-uk
>>
>
> --
> http://www.voidspace.org.uk/
>
>
> May you do good and not evil
> May you find forgiveness for yourself and forgive others
> May you share freely, never taking more than you give.
> -- the sqlite blessing
> http://www.sqlite.org/different.html
>
>
>
>
>
> _______________________________________________
> python-uk mailing list
> python-uk at python.org
> http://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