Domain-Driven Design in Practice: The RFU Case
How we achieved 80% automation through deep domain understanding.
The RFU case is a perfect example of how Domain-Driven Design works in practice. Instead of starting with a pre-made solution, we immersed ourselves in our client's business processes in the banking services sector. The result: An AI solution that not only works but speaks the language of the domain and automates 80% of manual work – with a break-even of just 1.5 months.
There are two ways to build AI systems: You can take a generic solution and try to adapt it. Or you can start with the domain and build the technology around it.
We always choose the second way.
The Generic Hammer Mistake
Many AI projects start with technology: "We'll take an LLM, fine-tune it a bit, and done." The problem: This solution doesn't know the business processes. It doesn't understand domain language. It doesn't know which validations are important and which errors are critical.
The result are systems that work in 80% of cases – but don't cover exactly the 20% special cases that are critical in daily business.
What Domain-Driven Design Really Means
Domain-Driven Design (DDD) isn't a methodology you "just apply". It's a philosophy that puts understanding the business domain at the center.
Concretely, this means:
1. Start with the business, not with technology
Before we talk about models, architectures, or frameworks, we ask: What problem are we solving? How does the current process work? What are the critical requirements?
2. Speak the language of the domain
In finance, there are "KPIs", "Risk Ratings", "Compliance Criteria". These terms are not interchangeable. The AI must speak the same language as the experts.
3. Model the business, not just the data
It's not just about processing documents. It's about business rules, validations, processes, dependencies.
4. Work with experts, not against them
The best solutions emerge when technology experts and domain experts work closely together.
The RFU Case: 500+ Pages, 80% Automation
Our client in the banking services sector faced a massive challenge: Analysts had to manually sift through hundreds of pages of annual reports daily to extract quantitative and qualitative KPIs.
The naive solution: Take an LLM, throw in documents, let it extract KPIs.
The problem: Which KPIs are relevant? How do you validate extraction? How do you handle contradictory information? What happens with edge cases?
Our approach:
- Domain analysis: We spent weeks understanding the process. Which KPIs exist? How are they defined? What are typical error sources?
- Formalize business logic: We made the analysts' implicit rules explicit. Which validations do they apply? Which cross-checks are necessary?
- Domain language as code: The software speaks the same language as the analysts. Terms like "EBIT", "Leverage Ratio", "Working Capital" aren't strings but business concepts with meaning and rules.
- Human-in-the-loop design: The AI extracts, but humans can verify. Every extraction comes with the exact location in the document and a justification.
The result: 80% of manual work automated, break-even after 1.5 months, higher quality through consistency.
Why Generic Solutions Fail
Imagine you take a generic RAG system and throw your documents in. What's missing?
- Domain logic: The system doesn't know what an "EBIT" is or how to validate it
- Business rules: No idea which cross-checks are necessary
- Context understanding: Can't distinguish between "EBIT 2024" and "forecast EBIT 2025"
- Error handling: Doesn't know what to do with contradictory information
Domain-Driven Design solves these problems not through more data or better models, but through better understanding.
The Hard Truth About Domain Knowledge
Acquiring domain knowledge is time-consuming. It means talking to experts, observing processes, gathering feedback. It means not starting to code immediately.
But it's the only way to build systems that don't just work but solve real business problems.
The difference is measurable: Systems based on domain-driven design have higher success rates, shorter break-even times, and better user acceptance.
Think From Domain to Technology
In the end, it's a question of perspective: Do I build a technical solution and hope it fits the problem? Or do I understand the problem first and then build the solution?
At Klartext AI, we always choose the second option. Not because it's easier – but because it's the only way to create sustainable, valuable systems.
Domain-Driven Design isn't a buzzword for us. It's how we work.
