by Eric Evans
When we set out to incorporate AI components into larger systems that are mostly conventional software, we encounter various difficulties. How do we wrangle behavior that is intrinsically non-deterministic so that it can be used in structured, deterministic systems? The flexibility of input is great! But the variation of output makes it difficult to do further processing by conventional software.
In this simple example I’ll characterize and constrain a non-deterministic result to make it usable in deterministic software. This leads into domain modeling and strategic design.
What follows isn’t rocket science, but it is the sort of basics I think we need to apply in order to get results.
1. A Question Conventional Code Can’t Easily Answer
Let’s start with a use-case I actually have. When I’m trying to get my bearings in a software system, I usually want to know what domains are addressed and in which parts of the code. So imagine an app that would generate that sort of view of a repo:
A list of domains addressed in the project, produced from a scan of the whole code-base.
Navigation to the relevant directories or files with high domain content, and lists which domains are addressed in each.
To start simply — a list of domains addressed in the project as a whole or in any given module.
To be concrete, let’s look at the open source project “OpenEMR”. Here’s a very small code sample from that project:
... continue reading