[python-uk] hexagonal Django
andy at reportlab.com
Wed Dec 5 14:28:56 CET 2012
On 5 December 2012 07:33, Chris Withers <chris at python.org> 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...
I have to admit my first thought on reading that page and diagram was
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.
More information about the python-uk