The Locator Pattern: Resolving Business References in Enterprise Systems
This article introduces the Locator Pattern as an architectural concept for resolving human-centric business references (like product codes) into canonical system identities (like GUIDs or primary keys) within a specific business context. It argues that this process is distinct from mere searching and is fundamental to business applications, transcending UI implementation details. The pattern emphasizes explicit context, handling ambiguity, and the transformation of language between users and systems.
Read original on Dev.to #systemdesignBeyond UI Controls: The Core Problem
The article begins by challenging the common misconception that selecting a business entity is merely a UI problem solvable by controls like a ComboBox. Instead, it posits a deeper architectural challenge: how to resolve a business reference provided by a user into a complete, contextualized business entity ready for further processing. For instance, typing "PROD-001" for a sales order product requires the system to not only identify the product but also determine its applicable sales price, unit of measure, VAT rate, and availability, all within the specific context of the current customer, price list, and document date.
Business References vs. Technical Identifiers
A key distinction is made between how users interact with systems and how systems operate internally. Users naturally employ business references (e.g., product codes, names, account numbers) that carry meaning within the business domain. Information systems, conversely, rely on unique, stable technical identifiers (e.g., primary keys, GUIDs, surrogate keys) for relationships and integrity. The Locator Pattern addresses the critical translation layer between these two conceptual worlds, ensuring the conversion is accurate and contextually relevant.
The Core Challenge
The fundamental question the Locator Pattern seeks to answer is not "Which information exists?" (search) but "Which business entity does the user actually mean?" (resolution within context).
The Locator Process Flow
The article outlines the conceptual steps involved in the Locator Pattern:
- Business Reference Input: User provides a human-readable identifier.
- Business Context Evaluation: The application considers the current operational context (e.g., customer, date, sales channel).
- Resolution: An attempt is made to map the business reference to a canonical identity.
- Canonical Identity Output: A unique, stable technical identifier for the resolved entity.
- Projection: Additional information required for the task is retrieved and returned based on the canonical identity and context.
Business Reference
│
▼
Business Context
│
▼
Resolution
│
▼
Canonical Identity
│
▼
ProjectionHandling Ambiguity and Resolution Failure
The Locator Pattern must gracefully handle various outcomes: no match, a single exact match, or multiple potential candidates. It distinguishes between business ambiguity (e.g., 5 matching products, allowing user choice) and resolution failure (e.g., 5,000 matches, indicating the reference is too broad). In the latter case, the system should prompt for a better reference rather than presenting an unmanageable list, highlighting that the problem lies with the input, not the display.
The Locator Pattern is presented as a fundamental architectural concept that is independent of UI or application type, applicable across desktop, web, services, data imports, and automated workflows. Its core purpose is to bridge the semantic gap between human business language and system-level identifiers within a specific operational context.