A plain-language guide to Domain Models

Over the years I’ve noticed something curious: almost every software system has a domain model… yet very few companies ever write it down.

In my last role, I remember two different customers — completely independently — asking whether we had a domain model that explained how API entities related to one another. They weren’t asking for new features or documentation changes. What they were saying, in essence, was: “We’re trying to piece together how these concepts fit, but it isn’t obvious from the API operations alone.”

Reflecting on professional interests

I recently read Supremacy by Parmy Olson, about the race to commercialise Generative AI. One thing that struck me was how both Demis Hassabis, the British entrepreneur behind DeepMind, and Sam Altman, the American entrepreneur behind OpenAI, started their ventures without a specific commercial goal. They were driven by curiosity and possibility. The money and commercialisation only came later, once they became allied with — and partly absorbed by — the giants of Big Tech, Google and Microsoft.

That made me stop and think: What would it look like to pursue professional interests purely for their own sake, without the constraints of short-term business goals?

Introducing the Model Context Protocol: Why it matters for product development

We’re still in the early days of building practical applications on top of Large Language Models (LLMs) like OpenAI’s ChatGPT, Google’s Gemini, or Anthropic’s Claude. But one thing is already clear: LLMs alone aren’t enough. To move beyond simple question-and-answer interactions, they need three things:

• Prompts – carefully designed instructions or templates for repetitive tasks.
• Resources – documents, databases, or other sources of context.
• Tools – APIs and system calls that let the model act in the real world, safely.