Ontology-Driven Development Beyond Domain-Driven Design

Recently I’ve been exploring how to integrate LLM-based AI systems into Java backend applications. One interesting challenge was designing a clean architecture where the backend communicates with AI services without making the system tightly coupled. What I learned: • Keep AI logic completely separate from core business logic • Use REST APIs as a bridge between backend and AI services • Design for scalability from the beginning (AI calls can be expensive and slow) It’s exciting to see how traditional backend engineering is evolving with AI. Would you say AI is becoming a core part of backend systems now?

Research Note: and AI-Native Enterprise Applications I have been exploring Spring AI and its role in integrating generative AI into enterprise Java systems. It is emerging as a strong abstraction layer for building intelligent applications using familiar Spring patterns. Spring AI provides structured support for: • Large Language Model integrations • Embeddings and vector databases • Retrieval-Augmented Generation (RAG) • AI agents and tool calling • Multi-model orchestration What makes it significant is its alignment with enterprise software principles while enabling modern AI architectures. Key research areas I found compelling: 1. Model Abstraction Unified interfaces reduce provider lock-in and simplify orchestration across models. 2. Retrieval-Augmented Generation Combining LLMs with vector search enables grounded, domain-aware AI systems for enterprise knowledge retrieval. 3. Agentic Workflows Tool calling and autonomous task execution open opportunities for intelligent workflow automation. 4. Semantic Infrastructure Embedding and vector support make semantic search and contextual memory practical inside business systems. Potential applications: - Enterprise AI assistants - Intelligent documentation systems - Autonomous support agents - Domain-specific copilots - AI-driven workflow automation Research Perspective: Spring AI may play for AI-native applications a role similar to what Spring Boot played for microservices—accelerating adoption through abstraction and developer productivity. Currently exploring its intersection with agentic AI and autonomous workflow systems. Interested in how others are using Spring AI for research or production use. #SpringAI #SpringBoot #Java #GenerativeAI #AgenticAI #RAG #EnterpriseArchitecture #SoftwareEngineering #Research

The Great Convergence: Java Meets AI Engineering Are you building a demo for the weekend… or a system that survives the next 10 years? Because right now, the industry is splitting. Python dominates the research world. But enterprises are asking a different question: “Are we rewriting our entire backend just to add AI?” The answer? Probably not. The shift is already happening We’ve moved from: CRUD systems → Intelligent systems → Autonomous systems What used to be a “User Service” is now expected to: • predict behavior • automate decisions • understand context If it doesn’t… it starts to look outdated. Why Java is back in the conversation The old argument was: “Java doesn’t have the AI ecosystem.” That’s changing fast — some would say it already has. According to a 2026 report from Azul, 62% of enterprises are already using Java to power AI functionality. That’s not experimentation. That’s production. Frameworks like: • Spring AI • LangChain4j • LangGraph4j …are making LLMs feel like native JVM components. Not scripts. Not experiments. Actual production systems. This is bigger than chatbots We’re now building systems that can: • Search by meaning, not keywords • Call real business logic • Adapt workflows when things break That’s not “AI as a feature.” That’s AI as infrastructure. The real distinction Python is great for exploring ideas. Java is built for running the ones that matter. If you’re a Java developer, you don’t need to pivot away. You need to lean in. Because the next generation of AI systems won’t live in notebooks. They’ll live inside the systems that already run the world. So the real question is: Are you building something cool… or something that lasts? #Java #LangChain4j #LangGraph4j #SpringAI #AI #SoftwareEngineering #GenerativeAI #SpringAI #EnterpriseTech

𝗗𝗮𝘆 𝟭𝟲 𝗼𝗳 𝟮𝟱 · 𝗥𝗔𝗚 𝗶𝘀 𝘁𝗵𝗲 𝗳𝗶𝘅 · 𝗪𝗲𝗲𝗸 𝟰 𝗬𝗼𝘂𝗿 𝗔𝗜 𝗶𝘀 𝗰𝗼𝗻𝗳𝗶𝗱𝗲𝗻𝘁𝗹𝘆 𝗿𝗼𝗻𝗴 𝗺𝗼𝗿𝗲 𝗼𝗳𝘁𝗲𝗻 𝘁𝗵𝗮𝗻 𝘆𝗼𝘂 𝘁𝗵𝗶𝗻𝗸 LLMs do not know your data They do not know recent events And when they do not know something They still generate answers That is the real problem Here is what changed today and why it matters for production systems On Day 16 of the 25 day GenAI Java Engineer plan the focus is on RAG architecture Retrieve Augment Generate The system that makes AI actually reliable 𝗦𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 LLMs have a knowledge gap ● Trained on past data only ● No access to your internal documents ● Limited context window ● Hallucinate when unsure This makes them risky for real world systems 𝗥𝗔𝗚 𝗶𝘀 𝘁𝗵𝗲 𝗳𝗶𝘅 Instead of relying only on training data ● Retrieve relevant documents ● Inject them into the prompt ● Generate answers using real context You do not change what the model knows You change what the model sees That is the core idea 𝗧𝗵𝗲 𝗳𝘂𝗹𝗹 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲 Every production RAG system follows the same flow ● Load documents from PDFs APIs databases ● Split into meaningful chunks ● Convert text into embeddings ● Store vectors in a database ● Retrieve relevant chunks for a query ● Augment prompt with context ● Generate grounded answers Two phases ● Ingest phase runs once ● Query phase runs for every request Understanding this separation is critical 𝗪𝗵𝘆 𝘁𝗵𝗶𝘀 𝗺𝗮𝘁𝘁𝗲𝗿𝘀 Without RAG ● Answers are based on training data ● High risk of hallucination ● No access to private knowledge With RAG ● Answers are grounded in your data ● Updated instantly without retraining ● Reliable for real use cases This is how production AI systems are built 𝗥𝗔𝗚 𝘃𝘀 𝗳𝗶𝗻𝗲 𝘁𝘂𝗻𝗶𝗻𝗴 ● RAG updates knowledge instantly ● Fine tuning requires retraining ● RAG is cheaper and flexible ● Fine tuning is for behavior and style Default choice for most systems is RAG 𝗧𝗵𝗲 𝘀𝗵𝗶𝗳𝘁 I stopped treating LLMs as knowledge sources And started treating them as reasoning engines Knowledge comes from your data Not from the model That is the mindset change 𝗪𝗵𝗮𝘁 𝗯𝗿𝗲𝗮𝗸𝘀 𝗥𝗔𝗚 ● Wrong chunks retrieved ● Too much context overload ● Mismatch in embedding models If you do not understand these Your system will fail silently 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗻𝗲𝘅𝘁 Day 17 embeddings deep dive Understanding cosine similarity Chunking strategy And why embeddings decide everything 𝗗𝗮𝘆 𝟭𝟲 𝗼𝗳 𝟮𝟱 This is where AI stops being a chatbot And becomes a knowledge system #Java #GenAI #SpringAI #LLM #AIEngineering #BuildingInPublic #100DaysOfCode #SpringBoot #RAG

𝐅𝐫𝐨𝐦 𝐀𝐬𝐬𝐞𝐦𝐛𝐥𝐲 𝐭𝐨 𝐀𝐈: 𝐀𝐫𝐞 𝐖𝐞 𝐌𝐨𝐯𝐢𝐧𝐠 𝐓𝐨𝐰𝐚𝐫𝐝 “𝐌𝐚𝐫𝐤𝐝𝐨𝐰𝐧 𝐏𝐫𝐨𝐠𝐫𝐚𝐦𝐦𝐞𝐫𝐬”?⁣ ⁣ There was a time when programming meant writing raw assembly instructions—painstaking, precise, and deeply tied to the machine. Then came high-level languages like C++, Java, and Python, abstracting complexity and unlocking productivity. Each leap didn’t eliminate programmers; it redefined what it meant to be one.⁣ ⁣ Today, we’re witnessing another inflection point.⁣ ⁣ With the rise of AI-assisted development, the act of coding is quietly shifting from writing logic to orchestrating intent. Developers are increasingly describing systems in markdown files, shaping behaviour through prompts, and letting AI agents generate, refine, and debug the underlying code.⁣ ⁣ Modern workflows now include:⁣ 𝐏𝐫𝐨𝐦𝐩𝐭-𝐝𝐫𝐢𝐯𝐞𝐧 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐦𝐞𝐧𝐭 where engineers define requirements in structured natural language⁣ 𝐌𝐚𝐫𝐤𝐝𝐨𝐰𝐧-𝐛𝐚𝐬𝐞𝐝 𝐬𝐩𝐞𝐜𝐬 that act as the single source of truth⁣ 𝐀𝐈 𝐚𝐠𝐞𝐧𝐭𝐬 that interpret plans, generate code, run tests, and even deploy⁣ 𝐑𝐮𝐥𝐞𝐬 𝐚𝐧𝐝 𝐠𝐮𝐚𝐫𝐝𝐫𝐚𝐢𝐥𝐬 to constrain outputs and enforce architectural patterns⁣ 𝐒𝐤𝐢𝐥𝐥𝐬/𝐭𝐨𝐨𝐥𝐢𝐧𝐠 layers where reusable capabilities are invoked rather than re-coded⁣ ⁣ In many teams, the code is no longer the first artifact—it’s a byproduct.⁣ ⁣Are we heading toward a future where developers rarely see code at all?⁣ ⁣ The answer is nuanced.⁣ ⁣On one hand, abstraction has always been the direction of progress. Just as most developers today don’t think in assembly, future developers may not think in syntax-heavy languages. Instead, they may operate at the level of:⁣ ⁣ System design expressed in markdown⁣ Intent captured through prompts⁣ Behaviour governed by rules and constraints⁣ Execution delegated to autonomous agents⁣ ⁣ In this world, the developer becomes a system orchestrator rather than a code writer.⁣ ⁣But here’s the catch: abstraction doesn’t remove complexity—it relocates it.⁣ ⁣ Understanding concurrency, performance, security, and edge cases will still matter. When AI generates code, someone still needs to validate it, reason about it, and intervene when things go wrong. Debugging may shift from stepping through code to analyzing prompt chains, agent decisions, and execution traces.⁣ ⁣ The future developer might ask:⁣ ⁣ Why did this agent choose this approach?⁣ Which rule caused this behavior?⁣ How did this prompt lead to that output?⁣ ⁣ 𝐈𝐧 𝐞𝐬𝐬𝐞𝐧𝐜𝐞, 𝐰𝐞’𝐫𝐞 𝐦𝐨𝐯𝐢𝐧𝐠 𝐟𝐫𝐨𝐦 “𝐇𝐨𝐰 𝐝𝐨 𝐈 𝐰𝐫𝐢𝐭𝐞 𝐭𝐡𝐢𝐬?” 𝐭𝐨 “𝐇𝐨𝐰 𝐝𝐨 𝐈 𝐝𝐞𝐬𝐜𝐫𝐢𝐛𝐞 𝐭𝐡𝐢𝐬 𝐜𝐨𝐫𝐫𝐞𝐜𝐭𝐥𝐲?”⁣ ⁣ And that’s a profound shift.⁣ ⁣ The real evolution is not the disappearance of coding—it’s the elevation of programming to a higher level of abstraction, where intent, clarity, and system thinking matter more than syntax.⁣ ⁣ The engineers who thrive in this new era won’t just be great coders.⁣ They’ll be great communicators with machines.

I use AI tools every day. They help me write faster, explore ideas faster, and get unstuck faster. That part is real. But I think many senior developers feel the other side of it too: the work did not disappear. It moved. In enterprise Java, AI often gives you code that looks clean, plausible, and production-ready. It compiles. It boots. It even passes more checks than it probably should. And that is exactly why the human cost is still there. Maybe even more than before. Less typing. More supervision. More semantic review. More mental context switching. More carrying half-finished judgment into the evening. I wrote about that here, from a Java and Main Thread perspective: https://lnkd.in/duhPeeft #Java #EnterpriseJava #SoftwareEngineering #ArtificialIntelligence #DeveloperProductivity #Leadership

Stop treating LLMs like black boxes and start treating them like microservices. Most "GenAI Developers" are currently stuck in the "vibe check" phase of engineering. If your evaluation strategy is just you and a coffee looking at five outputs, you don’t have a product; you have a demo. Moving from a RAG POC to a production-grade Agentic system requires more than a spicy system prompt. It requires a disciplined LLMOps Stack. Here’s the architectural reality check: ⚡Prompt Engineering vs. Prompt Management: If your prompts aren't versioned, tracked, and unit-tested like your Python/TS code, you’re one "minor model update" away from a total system regression. ⚡The RAG Relevance Loop: Retrieval isn't a "set it and forget it" task. If you aren't measuring Context Recall and Faithfulness (RAGAS style), you’re just serving hallucinations with extra steps. ⚡Tool/Function Calling Ops: This is the most underrated failure point. An agent is only as good as its error handling. If your tool execution lacks retries, circuit breakers, and schema validation, your agent is a liability. ⚡Evaluation is the New Compiler: In GenAI, we don't just check for syntax. We need an LLM-as-a-Judge or heuristic-based eval to measure semantic drift in real-time. The Bottom Line: An architect’s job is to minimize the "blast radius" of a non-deterministic model. This stack (check the infographic) isn't overhead—it's your safety net. #GenAI #LLMOps #SystemDesign #MLOps #Architecture #SoftwareEngineering #RAG #AgenticWorkflows

🚀 Understanding the Mechanics of Generative AI (For Spring Developers) As Java & Spring developers, we’ve always worked with deterministic systems: 👉 Input A → Output B But Generative AI changes the game. It introduces a probabilistic paradigm where systems predict the most likely output instead of retrieving fixed answers. 💡 Example: When you ask an LLM, “What is the capital of France?” It doesn’t fetch from a database — it predicts “Paris” as the highest probability token. 🧠 Core Concepts Every Spring AI Developer Should Know 1. Transformer Architecture Modern LLMs like GPT, Llama, and Claude are based on Transformers. ✔ Process entire input at once ✔ Use attention mechanism for context understanding ✔ Handle complex relationships in language efficiently 2. Tokens = Real Unit of Computation LLMs don’t read words — they read tokens (numbers). 📊 Why it matters: • 💰 Cost → billed per token • 📦 Context window → limited memory (8K, 128K, etc.) • ⚡ Latency → more tokens = slower response 3. Hyperparameters (Control the AI Brain) 🔹 Temperature • 0.0 → deterministic (best for APIs, JSON, code) • 0.8+ → creative (best for content, ideas) 🔹 Top-P (Nucleus Sampling) • Controls probability distribution • Use either Temperature or Top-P (not both usually) 4. Prompt Engineering = New Programming Skill ✔ Zero-shot → no examples ✔ Few-shot → give examples for format ✔ Chain-of-Thought → “Let’s think step by step” 👉 You’re no longer writing logic… 👉 You’re designing context + instructions 5. Running Models Locally with Ollama Instead of relying only on cloud APIs: ollama pull llama3 ollama run llama3 ✔ No API cost ✔ Better privacy ✔ Works perfectly with Spring AI 🔥 Why This Matters for Spring AI Spring AI is not just another library — It’s a bridge between traditional backend systems and probabilistic AI models. 👉 You orchestrate prompts 👉 Manage context windows 👉 Tune model behavior 👉 Integrate AI into real-world APIs 💬 Final Thought We are moving from: ➡ Writing business logic ➡ To designing intelligent systems And honestly… this is one of the biggest shifts in software engineering. #SpringAI #GenerativeAI #Java #BackendDevelopment #LLM #AIEngineering #Ollama #SoftwareEngineering #TechTrends

Everyone hates overengineering. Not because it fails. Because it produces incredible results and doesn't make everything nice and neat. I posted about my 14-language trading system last week and got a comment asking why I don't just consolidate C, C++, and Rust into one language. "Needless complexity." "Why not move everything to Rust?" Because the C layer is 3K lines of hand-tuned SIMD kernels. The C++ signal engine uses Eigen and template metaprogramming for physics that doesn't port cleanly to Rust. Combined they're 19K lines vs 141K in Rust across 27 crates. These aren't three languages doing the same job. They're three languages doing three different jobs. And "just rewrite it" means rewriting 19K lines inside a 1.3 million line codebase with downstream consumers across multiple languages. That's not a refactor. That's a destabilization event. But the real issue isn't the technical argument. It's the instinct behind it. The instinct to simplify, consolidate, pick one tool, make it clean. That instinct has dominated software engineering for decades. And it's why most systems are slower, less precise, and harder to maintain than they need to be. Simplicity is a virtue when it serves the result. It's a crutch when it serves the engineer's comfort. Here's what "overengineered" looks like in practice: The IAE, an autonomous research engine inside the system, ingested 63,993 backtest trades and produced 6 recommendations. One sentence applied all 6. Monte Carlo median 12-month outcome swung from -$678K to +$1.72M. Zero blowup rate across 1,000 simulated paths. I left two AI models in an autonomous loop overnight, local Gemma designing, cloud Claude building, reviewing each other's work and committing to the repo. By morning: 171,000 lines across 56 commits. 24 Claude Code agents running simultaneously don't care that they're switching from Zig to Elixir to Julia in the same session. A team of 50 engineers would never agree to that stack. They'd compromise on three languages and everything would be worse. The people calling this overengineered are making language compromises right now that cost them performance they don't know they're leaving on the table. The Python shop that needs nanosecond latency. The Rust team that needs rapid statistical prototyping. The Go backend that needs real options pricing math.

Gen AI in production is ~10% model and 90% integration. That’s where Java wins. While everyone is focused on Python for AI, the enterprise world is moving differently. Spring AI reached GA in 2025, and even engineers from Netflix have contributed to its evolution. That’s a strong signal: AI isn’t replacing enterprise stacks — it’s being embedded into them. Here are 3 JVM frameworks quietly shaping this shift: --- Spring AI (the Spring way of doing AI) The Spring philosophy applied to AI: → Provider abstraction (OpenAI, Mistral, Gemini…) → RAG out-of-the-box → Function calling → Embeddings management If you know Spring Boot, you already know how to build AI features. AI stops being “something separate” and becomes just another bean in your application. --- Embabel (agentic AI for DDD) Where Spring AI connects models, Embabel builds agents. Agents that operate directly on: → Your Java entities → Your services → Your business rules This is not generic agent orchestration. This is agentic AI aligned with your domain model. --- Koog (JetBrains) A modern multi-agent framework from JetBrains. → Built in Kotlin, fully JVM compatible → Designed for orchestrating specialized agents → Focused on complex workflows and collaboration Agent systems, but with JVM rigor and structure. --- Why Java over Python for production? → Strong typing = fewer surprises in prod → Enterprise ecosystem = no need to rewrite everything → JVM = performance, scalability, maturity → Built-in alignment with compliance (GDPR, SOX, PCI-DSS) --- Python dominates model experimentation. Java dominates enterprise integration. The AI that creates real business value is not the one with the best prompt. It’s the one that: → integrates with existing systems → respects constraints → scales reliably Spring AI, Embabel, and Koog are enabling that next step. #Java #SpringAI #Embabel #Koog #EnterpriseAI #AgenticAI #LLM #SpringBoot #JVM #SoftwareArchitecture #AIEngineering