I have written in this Blog about our work on "The Event Model" which is based on the search for simplification in event-based modeling. Here are some of the simplification goals that we strive to achieve while designing the model. These are a high level goals.
1. Stick to the basics by eliminating technical details. Looking at designs and implementations of event-driven applications, one can observe that there are two types of logic: the business logic, which directly states how derived events are generated and how the values of their attributes are assigned, and supporting logic that is intended to enrich events, or query databases as part of the processing.
2. Employ top down, goal oriented design. Many of the design tools require logic completeness (such as referential integrity) at all times. This entails the need to build the model in a bottom up fashion, namely all the meta-data elements are required to be defined (events, attributes, data elements) prior to referring to them in the logic definition. Our second simplification design goal is to support top down design, and allow temporary inconsistency working in the “forgive” mode in which some details may be completed at a later phase. This design goal complements the “stick to the basics” goal, by concentrating on the business logic first, and completing the data aspects later.
3. Reduce the quantity of logic artifacts. In typical event processing application, there may be multiple logic artifacts (event processing agents, queries, or processing elements depending on the programming model) that stand for different circumstances in which a single derived event is being derived. Our design goal is to have a single logic artifact for every derived event that accumulates all circumstances in which this derived event is generated. This goal reduces the number of logic artifacts and makes it bounded by the quantity of derived events. It also eases the verifiability of the system, since possible logical contradictions are resolved by the semantics of this single logic artifact.
4. Use fact types as first class citizens in the model. In many of the models, terms in the user’s terminology are modeled as attributes that are subordinates of entities or relationships. In some cases it is more intuitive to view these concepts as “fact types” and make them first class citizen of the model, where the entity or event they are associated with is secondary (and may be a matter of implementation decisions). This is again consistent with the “stick to the basic” goal.
These goals are high level. I'll write more details in the future about the ways we chose to satisfy each of these goals, and discuss alternatives for doing that. I guess that over time we'll accumulate more simplification goals.
