Roy Berris
Software Architect at New Orange
Nijmegen, The Netherlands
Actions
Roy Berris is a software architect at New Orange in the Netherlands. The work comes down to translating between what the business means and what the software does, through solution design, tech leadership and hands-on building in .NET and Next.js. Roy works on integrations and APIs, legacy modernization and domain-heavy business applications, using Domain-Driven Design and Architecture Decision Records to keep decisions clear. Recent focus: designing APIs that AI agents can use, and making agentic development reliable instead of only fast.
Area of Expertise
Topics
200 OK, Business Not OK
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.
AI Already Builds Faster Than You Can Review
AI already builds faster than we can review. Give an agent a brief and it sets up a CMS in minutes: content types, fields, compositions, test content. Impressive, until you realise someone has to check all of it. On every site, after every change. The reviewer has become the bottleneck, and nobody dares to let the AI deliver on its own.
Every CMS team knows the agreements that make a site "ours": SEO on its own tab at the end, global content in one place, the same field limits everywhere. They live in people's heads and wikis. The AI receives them once in the prompt, context drifts, and on site seven the SEO fields end up under Content. Nobody notices until an content editor does, and who is to blame?
In this session I show a different approach. Don't try to make the AI predictable: sandwich it between two parts that are fixed.
A brief in plain language goes in, with an example of the result. AI turns it into a fitness function: rules a computer can check, reviewed once by a human. Your team's agreements become house rules: written once, applied to every project. Then the AI configures the CMS however it likes. How doesn't matter. Finally, a script with no AI in it compares the configuration and the delivery API against the rules. Thousands of checks in seconds, same answer every time. Red goes back to the AI as a precise instruction. Green goes live.
And then I break it, live on stage. Watch the checks catch what a human reviewer would miss, and the AI fix it without anyone explaining what went wrong.
You'll walk away with:
- A way to let AI deliver CMS work on its own, without the review work growing with it
- How to turn your team's unwritten CMS conventions into house rules that are checked automatically
- Why a headless CMS is a testable CMS, and how the brief becomes your frontend contract
- A pattern that isn't tied to one CMS: shown on Umbraco, also runs on any other
Target audience: CMS developers, solution architects, tech leads and agency teams who build and maintain many CMS sites. No AI experience needed; experience setting up content models helps.
Format: talk with live demo. Preferred length 45–50 minutes; a 30-minute version is possible.
Language: English or Dutch are both possible.
Demo: Umbraco 17 with uSync and the Content Delivery API, runs fully local, no internet required. Pre-recorded fallback available.
Demo is a working proof of concept: an AI agent configures a headless CMS from a plain-language brief, validated by four deterministic checks against the exported configuration and the delivery API. Includes a real team spec run through the method unchanged. At our company we use this in practice for a big account, not just a proof of concept.
Speaker background: not experienced but not new at speaking and attendee at meetups, previously spoke at DF23 and twice at Umbraco Community Day.
Concept: this talk is not only for CMS, the same is true for building operation business-driven APIs. Would like to transform the same concept on any topic on request. DDD, data, DevOps, try me ;).
First public delivery is not yet done, would like to try this talk at a meetup.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top