Will Hardy: free the developers¶

Tags: django, djangocon

Will’s talk is about domain specific frameworks. Regular reusable apps are often intended for end-users, not really for developers that want to extend and change the reusable app. So: a focus on end-developers instead of end-users.

Domain specific frameworks are supposed to be valid for a whole domain, not just for a specific use case. So a shopping framework would be valid for any kind of shop. If you’re a developer that knows a lot about a domain, what’s nicer than distill your knowledge into a domain specific framework instead of a specific app?

A domain specific framework is more effort. It also goes against a bit of the agile mentality as you build more customizability and more flexibility into the framework than you’ll probably use yourself.

Design approaches. One of the first steps to take is to determine the role your framework is going to play. Then identify your assumptions and opinions. That is tricky: your own opinions and assumptions might be wrong. Examine them. “Does everything have a title?”. “Is it always true that…”. For instance, his web shop application did not assume that everything had a catalog code, contrary to initial expectation. This meant that an NGO was able to use it, too, which didn’t really sell products but had actions.

Technical approaches. Django has generic relations (using the content types framework), which you can use to link your models to any other model. Another way is model subclassing: you cannot change or remove existing fields, but you can add extra ones. Another one: signals. Signals help keeping the apps decoupled. The jackpot is to go all the way and hook up your specific declarative syntax into Django models (total = myframework.Total(field_a, field_b)).

Important: documentation! Documentation is key.

Respect not only the end user, but also the end developer. Free them. Give them the freedom they need. Allow them to use their own models and just tie into your framework.