We spent twenty years arguing that the domain model belongs at the heart of our software. Then we handed our specifications to OpenAPI files and Jira tickets.

Ask a team for "the spec" today and you get a wire contract: endpoints, schemas, status codes, JSON properties. It tells you how bytes move over the network. It doesn't tell you why a refund can never exceed what was paid, or what "confirmed" means to the people who run the business. That knowledge lives in a wiki page that started drifting the day it was written. The tests check for a 200 OK, not for business truth.

The schema validates. The tests pass. The business logic is wrong.

In this session I turn it around: the specification isn't a transport schema, it's the domain model. And it has three layers.

Domain intent: the rules, the language and the invariants, written so domain experts recognise their own business in it.
Behavioural scenarios: executable specifications that test state transitions and rules, without any HTTP or database in sight.
Delivery contracts: OpenAPI, event contracts, database tables. Still needed, but downstream. Generated from the domain, not the other way around.

Structure your specs like this and the wall between functional design, domain modelling and testing disappears. One source of truth: readable for the business, binding for the developer, executable in the pipeline.

I'll show it with a real business process. First designed from the API contract down, so you can watch the domain drift. Then designed from the domain out, and we change the implementation underneath it, while the rules stay intact.

You'll walk away with:
- A clear split between domain intent, behavioural rules and wire contracts
- How to write functional designs as living domain models that developers and domain experts both trust
- A test strategy that verifies business invariants instead of status codes
- Practical ways to stop from dictating your domain model

Target audience: developers, software architects and tech leads working on business-heavy systems. Familiarity with APIs and automated testing is assumed; DDD experience helps but isn't required.

Format: talk with live demo. Preferred length 45–50 minutes. Shorter is possible.

Demo: [insert any stack you wish for the conference], runs fully local, no internet required. I need HDMI/USB-C and a power outlet.

Speaker background: speaker and attendee at meetups, previously spoke at DF23.

First public delivery: will try at meetups before big events, fresh topic so did not yet have the chance to speak at a meetup.