Takeaways:

1. Your business code is sacred
2. Protect it from your tools
3. Write tests; get a better design

https://ox.cx/design for more!

And follow Hynek on YouTube at @THE_HYNEK

Whenever possible, start with the domain model, then start engineering

"Complexity is not about how many keys I have to press -- it's about how difficult it is to reason about the consequences of what I'm doing"

- @hynek

If you follow this method, Hynek argues that you have lost control over your domain model and therefore over your business logic.

It's ok to have duplicative-looking types at the edges of your project! Like the web interface and the DB layer

You might have three (or more!) classes for the same thing and that's OK.

(with a h/t to Adam Montgomery)

There are multiple approaches to solving this tension!

I won't write down the first one because @hynek asked us not to.

But the next way (which is apparently worse?) is to use class-based validators and an ORM as the bread in a sandwich of your business logic

They do not make good bread and your domain model gets squeezed to death.

Conflicting goals exist in all meaningful apps

The Web API is dictated by what is best for the user, what's a good external standard, etc

The Database Schema is motivated by effective data storage, developer affordances, and performance

The Domain Model is dictated by the Business Requirement

All the shitty stuff should happen on the outside layer of your program.

Once it's inside, make it as nice as possible.

The shape of the data determines the shape of the code.

Next pressure: The Rising Sea.

The example here is a box-moving problem from Advent of Code.

Good solutions reflect a well-formulated Domain Model, a model of code and data that describes the domain of your business or problem

Good solutions often include The Darkness, the messy layer that connects the outside world to your Domain Model

This relates to how tightly coupled code is. Two pieces of code are coupled if they can only be understood by looking at both pieces

Testable code is better code for a number of reasons, but one of them is decoupling

This is the first pressure we're talking about, and it's a good one!

Business logic has consequences! User's lives can be affected or ended based on our code.

Canonical reference: Therac-25. Every programmer should look this up.

Business logic is the most important code in your application

This is where Design Pressure comes into play.

Why do we write software?

We write software to achieve a goal using tools. The core of what we're trying to accomplish is the "Business logic"

Business logic is the code that processes the data coming in to you application and does something with it to solve business needs

Starting with a hottake: ORMs and validation frameworks ruin your projects!

That's a hook to wake up the audience, what's the real story?

The _unreflected_ use of the above ruins a project.

We're not here to tell you to stop using your favorite tool. The emphasis is _unreflected_

This is a talk about exceptions, not rock music. Thankfully we're here for the #python

Starting with: who's willing to put their hands up when asked a question?

Who here has had something go wrong in a #python program

So what are the takeaways?

- Write obvious code. This means going beyond just "it works"
- Use or abuse the language to make clearer code!
- But don't jump the shark

Code and slides are at github.com/amyreese/pycon

(as a sidenote, this is the second time @amethyst has asked a room of developers if they want to "go east" or "sleep", and both times has had to force the game along because pythonistas just want to sleep)

Ahh and we've reached the point in all good talks where this becomes a loving attack on @glyph We already talked about async, so now lets use generators to make a state machine!

The punchline is this is doable, and you can make a text adventure in a state machine powered by #python generators.