Blog de Joe Freeman

Business and Technical events are an early, easy, way to capture activity, notify other systems of activity, capture technical changes, and log executed business functions. The information needed for those events tends to reside in specific steps in an execution flow. This means we often need to insert event generation probes in multiple places and at multiple levels. Product owners need visibility into any business functions or services that are performed.  Technical teams need visibility into the detailed activities executed in a system.  Partner business functions and data stores need a way to reconstruct the data as it existed at a specific times Databases often only provide a current or point-in-time state.  Logs have PII restrictions. Metrics are statistical by their nature. 

Software systems stream business events to be seen by customers, used by processes, or written to analytical stores.  Sometimes the best way to initiate a design is to create a grammar, a language, that can be used to generate the data models used in the events. Our first step is to define the  grammar or syntax for  Business Events / Audit Messages in a generalized form. We use this grammar to validate design time event definitions. We can implement that grammar in whatever technology we choose. Business Events are different from technical events. Programs and subsystems generate technical events about invocation and process failure events.  Technical events are targeted at production support, system triage, and data store replication.  Customers and other users expect to see activities in human-readable form. These activities are referred to as  Business Events  or  Business Audits . They define operations one level higher than  Technica...