Managing the Data Lifetime and Access Through Scoping

March 29, 2014

Software developers think of the lifetime of data or objects within the confines of the language or frameworks they are using. They need to think of data lifespan or scope as a first class component of design.

Business and business process data is valid for some period of time. It has a lifetime, scope, that may vary based on business rules, transaction time or some other function. Technical or software transaction data is also scoped, valid for some period of time.

This talk focuses on how these lifetimes can be more naturally integrated into a running software system.

Lifespan

Every business entity, attribute or property is valid for some period of time. It may be the lifespan of a project, a contract period , the length of time someone is a customer.

Transient copies of the data or newly created business entities may be valid for the life of some user session or only while some transaction operation is active. This means applications often operate on data with overlapping lifespans, or scopes. Global customer information is valid during a session while a reservation, policy or loan update is only valid until it committed to some back-end system. Think about larger state-full applications where transactions can span multiple pages or where multiple different transactions are integrated into a single software flow.

Good software design takes into account this mixing of lifespan. We want to plan ahead by grouping related data and same scope data. We also want to build infrastructure that makes data cleanup and reset easier and more reliable. Good frameworks mean more reliable data with less mixing or missed cleanup. The best systems support both explicit and implicit lifecycle management.

Teams can ignore pieces of this discussion when working simple forms based CRUD applications where a page maps to a table and where each submission commits data independently.