Domain Knowledge Is the New Force Multiplier
As AI shifts the focus from implementation to understanding, we explore spec-driven development, interrogatory LLMs that uncover hidden assumptions, and why system boundaries begin with ownership, not deployment.
Whether you are using Microservices or a modular monolith, getting the boundaries right is key to leveraging the benefits those architectural choices are meant to bring. Yet, it is common to fall into the trap of using the wrong criteria to do so.
The result? A seemingly decoupled change in a system/module has ripple effects on another one.
This article explores the topic and proposes that many use the physical aspect as the only one when deciding the boundaries.
Instead, we should focus on ownership to begin our discussion. Who owns the rules, lifecycle, and has the authority over the meaning of the concepts handled?
This comes with the realization that while physical boundaries are important, they should not dictate the logical boundaries. Ultimately, physical boundaries represent how you decide to deploy and connect modules/services, and that is about it.
How to get it right, then?
Well, this is where language matters, and sometimes the “same” thing is actually different, and that is a hint for the boundary discussion. Ubiquitous language, anyone? :)
For example, we may be talking about an employee, but for HR and IT, they represent two different concepts.
HR will care about compensation, benefits, onboarding, and offboarding. IT will think about authentication, roles, and applications.
Two reminders:
It is unlikely that getting the boundaries right will happen on the first try, so don’t give up.
As your understanding and the business itself evolve, what was right before may need to be revisited and split
Domain Knowledge Is The Leverage
“What makes code easier for humans to work with are almost the same things that make code easier for agents to work with.”
I recently saw the above comment in an article, and it reminded me of a past discussion I had while writing about the SOLID principles. The discussion was on the lines of “those practices/principles are no longer relevant now that LLMs are writing a lot of the code”.
My take is also that well-designed code, where the concepts are clear, helps by preventing the agent from having to read the entire codebase to understand what your code does, and that is not going away anytime soon.
At the same time, LLMs can now generate code of sufficient quality for many business fields. This shifts the focus of developers from “how I will implement this” to understanding the domain and how it manifests itself as code.
That is one reason why we see the rise of spec-driven development, where the decisions about interfaces, dependencies, and constraints feed the agent what it does not know.
Now, as with any new approach (microservices, NoSQL, Cloud), we need to resist the urge to overcompensate.
For those who suffered from the “abuse” of Agile misunderstandings that looked at any form of planning as a heresy, don’t revert to a waterfall and demand pages-long requirements before you can begin your implementation.
3 key questions you want to keep asking:
What is the problem we are trying to solve
Why is it a problem
Who should be solving this problem
You will be surprised by how often that changes the solution you (and the LLM) would implement.
Interrogatory LLM
A crucial part of software development consists of taking requirements and specifications to translate them into the artifacts (code) that will power the solution.
In our AI-assisted workflow, this means providing those documents to LLMs. It is paramount that someone writes these documents.
Unfortunately, writing is not something that is natural to all. In fact, it can be hard for many, making development, AI-assisted or not, difficult.
A potential solution to keep the human in the loop is the concept of interrogatory LLM, where we prompt the LLM to interrogate you about something and then capture your answers in a standardized fashion that your team can consume.
I have been applying this via the use of agent skills that accept the initial context as part of the prompt itself, or by providing some document as a starting point. The LLM then reads the document and inquires me (or a domain expert) to close ambiguities before outputting the final result.
This has helped me to still be in control, provide the idea, but have early feedback on things that, while clear in my head, were not evident on paper, and even points that I haven’t yet considered. Additionally, I focus on the content and less on the format, which is handled by the LLM as it follows the template I provided.