Fundamental Concepts of Business Applications III: Locator Definitions

In the previous article, we argued that a Locator is neither a UI control nor a search mechanism. It is an architectural concept that resolves business references within a specific business context and transforms them into canonical business identities.

If that is true, however, an obvious question immediately follows.

How can a Locator be described?

Not how it is implemented.

Not how it is executed.

But how it can be described independently of any particular implementation.

This question is more important than it may seem at first glance. If two different development teams decide to implement a Locator, how can they be sure they are implementing the same concept? How can we discuss a Locator without referring to a particular library, programming language, or framework?

The answer is that, like any mature architectural concept, a Locator must first be separated from its implementation.

This distinction appears repeatedly throughout the history of software engineering.

Relational theory existed before relational database systems.

SQL does not describe how a query will be executed. It describes only the result we want to obtain. The choice of indexes, execution plans, and optimization algorithms is the responsibility of the query optimizer.

Exactly the same principle applies here.

A Locator should not be defined by the mechanism that implements it.

It should be possible to describe it independently of that mechanism.

This naturally leads to three distinct levels of abstraction.

Locator Pattern

        │

        ▼

Locator Definition

        │

        ▼

Execution Engine

The Locator Pattern is the architectural concept itself.

The Locator Definition is the declarative description of a particular resolution process.

The Execution Engine is the component responsible for interpreting that description and performing the actual resolution.

Each level has a different responsibility, and they should never be confused with one another.

This means that a Locator Definition is not an implementation artifact. It is neither a class, an API, a SQL query, nor a UI component.

It is a declarative description of a business reference resolution process.

Or, if you prefer, it is the contract that defines what it means to resolve a particular business reference without describing how that resolution should be performed.

This naturally leads to the next question.

What is the minimum amount of information required to describe a Locator completely?

The answer is that every Locator Definition must answer a small number of fundamental questions.

1. What can be resolved?

Which business entity is being resolved?

A Product?

A Customer?

A Warehouse?

An Account?

Notice that we are not talking about database tables or object-oriented classes.

We are talking about business concepts.

2. How can it be referenced?

How can users refer to that entity?

By code?

By name?

By barcode?

By registration number?

By account number?

These references represent the user's language rather than the internal language of the information system.

3. Under which business context?

The same business reference may represent different entities depending on the business context in which the resolution takes place.

The company.

The warehouse.

The customer.

The transaction date.

The active price list.

The actual values of this context belong to runtime. A Locator Definition does not contain those values. It merely describes that the resolution process may depend on them.

4. What is the canonical result?

If the resolution succeeds, what is the canonical business identity that is produced?

From that point onward, the rest of the application can safely use this identity without knowing how it was obtained.

5. What information becomes available after successful resolution?

Successful resolution produces more than a business identity.

It also makes available the information required for the business process to continue.

For example, resolving a product may also provide its description, unit of measure, VAT rate, or any other information required by the current business process.

The important point is that a Locator Definition does not describe specific fields. Instead, it defines the contract of the information that becomes available after a successful resolution.

Optionally, a Locator Definition may also describe the abstract source from which entities are resolved. That source is not necessarily a relational database. It may be a service, an object collection, or any other provider capable of participating in the resolution process. Even this information remains part of the description rather than the implementation.

It is equally important to understand the boundaries of a Locator Definition.

Its purpose is not to describe the technical details of execution. It does not define SQL, indexes, execution plans, caching strategies, or search algorithms. Nor does it dictate dialogs, combo boxes, grid controls, or any other user interface elements.

Those are the responsibility of the Execution Engine, which is free to choose the most appropriate implementation as long as it honors the contract defined by the Locator Definition.

In this sense, a Locator Definition resembles a small declarative language more than it resembles a class or an API.

It does not describe objects, algorithms, or implementations.

It describes a business intent.

It answers only one question:

What does it mean to resolve this business reference?

Everything else is the responsibility of the mechanism that interprets and executes that description.

So far, we have not written a single line of code.

And yet, we have already defined an architectural concept, the language used to describe it, and the information that such a description must contain.

This is perhaps the most important characteristic of a declarative architecture. The concept comes first. The description remains stable, while the mechanism that executes it may evolve, be replaced, or be completely redesigned without changing the concept itself.

The next natural question is therefore no longer what a Locator is, nor how it is described, but how such a declarative description can be transformed into a real, working software component.

That is the software engineering problem we will explore in the next article.

Fundamental Concepts of Business Applications IV: Building a Locator