Re: [python-uk] hexagonal Django

[Chris Withers]

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?


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...


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@python.org
http://mail.python.org/mailman/listinfo/python-uk

Re: [python-uk] hexagonal Django

[Michael Foord]

On 5 Dec 2012, at 07:33, Chris Withers  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.

> 
> 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@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@python.org
http://mail.python.org/mailman/listinfo/python-uk

Re: [python-uk] hexagonal Django

[Matt Hamilton]

On 5 Dec 2012, at 07:33, Chris Withers wrote:

> 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…

Or more correctly, architecturally brilliant so much so that it was taken forth 
to be used outside the platform to such a degree that the rest of the platform 
(Zope 3) was refactored out as a bunch of standalone libraries (The Zope 
Toolkit).

To the OP: The Zope Component Architecture may cover quite a bit of what you 
want to do… take a look at zope.component and zope.interface (or read up here 
http://bluebream.zope.org/doc/1.0/manual/componentarchitecture.html)

-Matt

-- 
Matt Hamilton, Technical Director
Netsight Internet Solutions Limited
http://www.netsight.co.uk/matth
Tel: 0117 90 90 90 1 Ext. 15

Registered in England No. 3892180
Registered office: 40 Berkeley Square, Clifton, Bristol, BS8 1HU

___
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk

Re: [python-uk] hexagonal Django

[Andy Robinson]

On 5 December 2012 07:33, Chris Withers  wrote:
> 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...

ROTFL!

I have to admit my first thought on reading that page and diagram was
"architecture astronauts"...

If you're building a system which will last many years and tie
together a core business, AND it really needs a rich internal object
model embodying "business rules", yes, maybe this approach is valid.
A core ERP system or some kinds of financial modelling systems spring
to mind.  Basically, a project which can justify a core team of 3-6
people working on it long term.

But if you really need a company database, and a variety of web front
ends and interfaces to it including CRUD, and budgets/timescales are
limited, then there are huge efficiency savings all round for trying
to do things "by the book" in Django, and using models as your
business objects.  New developers know where to look for things, and a
lot of so-called business rules are easily implemented by save methods
and signals.   And there are established best practices for testing.

This week we had to help an overseas firm add a reporting capability
to their Django app.  They sent over a copy of the code, and their
development practices were amazingly similar to ours, and we had it
running in an hour or so.   Everything was where you expected to find
it.  If we had needed to trace through 3-4 layers to understand where
one factoid came from, life would be a lot harder.

I do fully agree with having an agreed dependency graph.   We will
often centralize the 'non-Django' parts of an application as helper
functions inside a python module, inputting and returning just
primitive Python tests, and write unit tests for those.   But that's
more a matter of having a well written "utils.py" in an app than of
reimplementing everything outside of your framework.

Cooperating web services have also helped deal with the interfaces
problem.  Big hairy corporate systems are often broken down now into
reasonable sized chunks that POST and GET to each other, so you don't
need quite so many layers and adapters in the code of any one of them.


Just my grumpy-old-man 2p worth.
-- 
Andy Robinson
___
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk

Re: [python-uk] hexagonal Django

[Jonathan Hartley]

On 05/12/2012 13:08, Michael Foord wrote:

On 5 Dec 2012, at 07:33, Chris Withers  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@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@python.org
http://mail.python.org/mailman/listinfo/python-uk



--
Jonathan Hartleytart...@tartley.comhttp://tartley.com
Made of meat.   +44 7737 062 225   twitter/skype: tartley

___
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk

Re: [python-uk] hexagonal Django

[John Lee]

On Tue, 4 Dec 2012, Jonathan Hartley wrote:

The last few weeks I've been thinking about the architectural pattern known 
as Clean, Onion, Hexagonal, or Ports'n'Adaptors 
 
(http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html). 
I'm curious if many people are applying it in the Django world?


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.


I have to confess I've only very lightly skimmed the article (which looks 
like it says some sensible things), but that's not going to stop me 
pontificating in over-general terms and posting a video that I liked:


The best programmers I've worked with have a knack to ruthlessly pick the 
simplest possible abstractions to fit the job in hand.  They never stop 
thinking to settle on any one-size-fits-all programming style.  The 
problem with those two statements I just made is that everybody can read 
them and think that they agree with them.  What *I* mean by simple is 
close to what Rich Hickey means in the first part of this talk (though I 
don't know enough to decide what I think about how he goes on to defend 
Clojure and its design principles in those terms):


http://www.infoq.com/presentations/Simple-Made-Easy


(BTW, it's a shame to hear him give security as an example of a separable 
concern, because it isn't one)


The best code, you look at the functionality, then the code, and think 
"where is all the code?" and "how did such simplistic code happen to 
implement exactly what was needed?".  That's different from the "OMG, what 
is all this stuff for" feeling you get from over-engineered or just 
badly-factored code.  The best code is easy to change in the sense that 
changes in functionality require commensurate coding effort, and it's 
clear what code would have to change.  But it is also hard to change, in 
the sense that any change that leaves the behaviour the same would clearly 
make it worse -- including adding or removing abstraction.


I'd agree with Andy that not fighting too many battles with your framework 
has a lot to be said for it (and that it's maybe more important to nail 
basic coding practices of the kind you'd find in Code Complete than to 
take even a single step away from what the django tutorial tells you to 
do).  But even short programs can gain simplicity from ignoring the 
framework or abstracting it a little, where it suits the problem, as it 
often does.



John
___
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk