Many engineers are scrambling to understand transformers, fine-tuning, and neural networks. They're learning Python, PyTorch, and prompt engineering. Racing to become AI experts.
Unless you're already in Silicon Valley or planning to relocate to Shanghai tomorrow, you're probably too late.
By the time you develop demonstrable ML expertise, the models will be training themselves. The field will belong to people who've already invested years mastering the mathematics and engineering behind these systems. That ship has sailed.
But there's another ship just leaving port. And this one might be more accessible to most of us.
The opportunity
For twenty years, Domain Driven Design has quietly powered many of the world's most complex systems. Investment banks use it to model derivatives trading. Logistics companies use it to orchestrate global supply chains. Healthcare systems use it to manage patient care pathways. DDD works. It's battle tested. It's just been the domain of specialists and enterprise architects.
In my view, that's about to change dramatically.
As we shift toward AI-first systems, those same DDD concepts may become the primary interface between human understanding and machine intelligence. The practices that enterprise architects have been refining for decades? They're about to become the most valuable skills in technology.
Think about what's really happening right now. We're moving from a world where humans write instructions for computers to one where humans explain intentions to AI. That's not a technical problem. It's a communication problem. A modelling problem. A domain problem.
Event Storming for AI
If you've never experienced event storming, here's the basic idea. You get all the stakeholders in a room with a wall of sticky notes. Everyone writes down events that happen in the business. "Order placed." "Payment failed." "Inventory depleted." You arrange these events in sequence. You identify the triggers, the actors, the outcomes.
The magic happens when you discover the edge cases. The exceptions. The unwritten rules that everyone just knows but nobody's documented.
Traditional event storming produces shared understanding among humans. But imagine feeding that same event map to an AI system. Suddenly you're not just aligning people. You're programming an intelligence. Same sticky notes, revolutionary new purpose.
Language as the new API
DDD insists on ubiquitous language. If the business calls them "customers," the code should too. Not "users" or "accounts" or "entities." Customers. This felt pedantic when we were writing code. Who cares if the database table is called usr_acct when the business says "customer"?
When your interface to technology is conversation, language precision becomes everything.
The AI needs to understand that when you say "customer," you mean someone who's made a purchase, not just anyone who's signed up. That distinction might determine whether someone gets a loyalty discount or not. Whether they receive certain communications. Whether they can access specific features. The ubiquitous language isn't just nice to have anymore. It's the entire interface.
Consider how this plays out in practice. A retail company might have seven different definitions of "product" across their organisation. The inventory team uses it for physical items in warehouses. Marketing uses it for sellable concepts that might bundle multiple physical items. Finance aligns it to SKUs. Customer service uses it to mean anything a customer asks about, including services and warranties.
In a traditional system, we'd build complex mapping layers to reconcile these different views. Tables joining tables. Integration middleware translating between contexts. But AI systems can hold all these contexts simultaneously. They can understand that when the warehouse manager talks about products, they mean something different than when the marketing manager does. But only if someone has done the work of defining these contexts clearly. Only if someone has mapped the domain.
So, how does it play out?
Companies will realise they need specialists who can articulate their business domains to AI systems. Not prompt engineers. Not ML experts. Domain translators. People who can run an event storming session on Monday and have an AI system understanding the business by Friday.
These won't be technical roles in the traditional sense. They'll be more like business analysts with superpowers. Part anthropologist, part systems thinker, part storyteller. They'll need to understand DDD concepts deeply. But more importantly, they'll need to understand how to extract domain knowledge from people who don't even realise they have it.
Consulting firms are already starting to position for this. They're rebranding their business analysts as "AI transformation specialists". Many don't even realise they are DDD experts and aren't familiar with the nomenclature, but when you break down their objectives, it's DDD 101.
My bet is that people who can walk into a mid-sized business and systematically capture decades of operational knowledge in a form that AI can use will win big.
Imagine being the person who helps a regional bank teach AI systems how their lending process really works. Not the official process in the manual. The actual process, with all its quirks and exceptions and relationships. Or helping a manufacturer capture the knowledge of their most experienced floor supervisors before they retire. This is the real AI transformation. Not building chatbots or automating reports. Teaching AI systems how businesses actually operate.
Beyond code, into understanding
I've spent the last fifteen years pushing CQRS and event sourcing. Arguing that storing events is superior to storing state. That command-query separation leads to cleaner architectures than CRUD. These patterns made sense for complex systems, but they were hard to implement. Event stores. Projections. Eventual consistency. Most teams decided the complexity wasn't worth it.
But AI systems naturally think in terms of events and narratives. They can replay histories to understand patterns. They can project forward to predict outcomes. What was architecturally complex becomes conceptually simple when your system understands stories rather than executing procedures.
This is the shift we need to make.
We're not just moving from imperative to declarative programming. We're moving from programming to explaining. From syntax to semantics. From code to comprehension.
The skills that actually matter
So what should you actually be learning right now? Not PyTorch. Not transformer architectures. Leave that to the specialists who've already invested years in the field.
Learn how to see systems. Really see them.
Learn how to facilitate event storming sessions. How to get a room full of domain experts to share what they know. How to ask the questions that surface hidden complexity. "What happens when that fails?" "Who decides that?" "How do you know when that's done?"
Master the art of bounded contexts. Understand why "customer" means different things in different parts of the organisation. Learn to spot the translation points.
Study aggregate design. Not the technical implementation, but the conceptual modelling. What data changes together? What rules must be enforced atomically? These aggregates will become the building blocks that AI systems use to understand business operations.
Practice building ubiquitous languages. Create glossaries that capture not just definitions but context and relationships and constraints. Document the business rules that everyone knows but nobody's written down. The exceptions that make the system real.
Armed with these skills you can run workshops that produce domain models instead of software requirements. You'll help organisations understand themselves well enough to explain themselves to machines.
The journey ahead
Becoming an AI expert and becoming a domain modelling expert aren't mutually exclusive. They're complementary skills that will define the next generation of technology leaders.
Keep using AI daily. Even learn how they work (for fun). But, more importantly, discover how to get the most from each model. Customise system instructions, build specific personas, utilise projects, knowledge, tools, and artifacts. But don't mistake this for learning how to be valuable to businesses when they're ready to overhaul their systems and become AI-first.
The professionals who can do both - who can speak fluently to both AI systems and business stakeholders - will be the architects of our AI-first future. They'll be the ones teaching AI systems not just what to do, but understanding why it matters.
Every business will eventually need to make this transition. When they do, they'll need people who can bridge the gap between human complexity and machine intelligence. People who can take decades of accumulated business wisdom and translate it into something an AI can understand and act upon.
The machines are ready to learn. The question is: are you ready to teach them?