AAF Data

Locally-Sourced, Artisanal Data™

Delivering Foundational Organizational Agility

AAF Data is the crucial first layer — business entity data modeling and persistence — of the Adaptív Application Foundation (AAF).

Today, AAF Data is:

• A standalone set of
  • Generalized business entity models,
  • Database creation scripts for roles, schemas, tables, functions, and
  • Scripted lookup/reference data,
• A Dockerized, RESTful business entity microservice (BEM) providing
  • Basic CRUD operations
    • Create,
    • Read,
    • Update,
    • Delete, and
    • SwaggerDoc OpenAPI application programming interface (API) documentation.

We have ORMs, Repository pattern, and DTOs. Isn’t data a solved problem?

In a word, no.

None of these technologies and tools address or encourage good data design, and all of them lead us down ever more compromising paths that result in unnecessary and expensive code creation and maintenance and poor data design and performance and that shift data operations from the database server, where they belong, to the service layer, forcing all kinds of anti-pattern trade-offs.

“Data is absolutely foundational to information systems. If the data ain’t right, ain’t none of it gonna be right. At the very least, teams will spend lots of unnecessary time coding around or in place of things that could and should have been established clearly in the data layer with just a little thought and discipline.

The data layer — database roles, schemas, tables, columns, data types, indexes, constraints, functions/stored procedures, Structured Query Language (SQL) scripts to create all this structure and to provide reference data, etc — is there to work for us, not the other way around. It’s important that we understand and use the right tools for a given job and that we wisely invest the time to design and create a structure that will pay dividends for years. Yes, this is not only possible but absolutely crucial to your long-term success and that of the organizations you serve. Use the data layer to model business entities and relationships and to persist their data. Design it to collect a complete, consistent data set from day one rather than only adding data elements when they’re asked for.“

— How Bad Things Happen … in the Data Layer

Object Relational Mappers (ORMs)

• Are entirely unnecessary, if database column names, service property/attribute names, and user interface (UI) widget field names are all derived from a model and are therefore the same in the data layer, service layer, and presentation layer.
• Don’t typically encourage custom roles with different privileges, e.g. database owner, database administrator, read/write, read-only, etc, an omission that can easily result in dangerously overprivileged database access and compromised data security.
• Don’t encourage thoughtful entity or attribute naming, which is vitally important and should therefore be intentional. In AAF Data we wisely invest time thinking carefully about names or adopt naming established by those who have thought carefully in the past.
• Don’t encourage consistency, completeness, or specificity. In AAF Data we name attributes clearly, e.g. CreatedAtDateTimeUtc, in consideration of our fellow “downstream” developers, report writers, analytics developers, and data scientists, who need to know what to expect without the need to create and maintain a separate data dictionary.
• Do encourage (and exist in order to facilitate) data entity definition in the service layer — a dangerous anti-pattern that combines:
  • Business data entities that represent the nouns — the persons, places, and things — that our information systems are intended to manage,
  • Business processes that represent the verbs — the actions that operate on and orchestrate the interactions of these entities, and
  • Business rules (or “decisions”) are the logic and conditions that inform and constrain these processes.
• Don’t typically “layer” data validation by leveraging the database server’s built-in and highly efficient constraints, referential integrity, etc.
• Don’t seem to understand that any system can be modeled using:
  • Business Entities (e.g. Person, Organization, etc, which can contain scalar text-based and numeric data, as well as foreign key references),
  • Associations (e.g. Employee, which associates a Person with an Organization using their Id values as foreign keys), and
  • Hierarchies (e.g. OrganizationalUnitHierarchy, which can represent hierarchical structures using OrganizationalUnit Id foreign key values as ParentOrganizationalUnitId and ChildOrganizationalUnitId)
• Don’t discourage poor attribute grouping that often results from the lack of a clear business entity concept, leading to data attributes that actually belong to several different entities being thrown together in a single database table.
• Discourage the use of database stored procedures/functions. There’s a lot of value to being able to essentially conduct an application’s data operations through the same stored procedure data access layer called from the service layer, and there are certain things that can only be done server side in the database.

The result of all of this is that unexamined, unchallenged, poor data design gets “baked into” the data layer every day and then impedes progress and costs the organization, its stakeholders, and its customers money and time forever, rarely if ever getting fixed because it’s in the foundation, and changing the foundation can put the whole Jenga stack at risk.

It is the mission of AAF Data to provide a clear, complete, consistent, and performant alternative to all of this.

AAF Data Features

AAF Data Rules

Soon AAF Data will also include:

• Terraform scripts for creating AWS infrastruture and deploying the AAF Data services to the cloud,
• JWT helper functions (encode/decode),
• A business entity modeler web application and service for extending or modifying these models and their scripted data,
• A structure service for conforming the entity data structures to the model, and
• CRUD operation event publishing.

AAF Data Screenshots