OpenSignals is the right kind of Domain-Oriented Observability

For many engineers new to observability, and application performance monitoring for that matter, domain-oriented observability looks very much like adding interceptors and callbacks into an application codebase to simplify the calling out to a generic data collector library such as distributed tracing, metrics, or even logging as a last resort. Unfortunately, the domain-oriented approach rarely reflects the needs of a useful service level management framework because it becomes lost within the business domain’s details. The pendulum seems to swing between two extremes, highly domain-specific named callbacks, or generic non-descriptive data sinks.

A highly domain-specific approach to observability ends up with hundreds of <Task>Instrumentation interceptor like interfaces containing various lifecycle hook methods that mirror the business function, such as startCreateOrder, failedCreateOrder, and completedCreateOrder – a significant step backward from what was hoped with Aspect-Oriented Programming (AOP). This approach lacks the required level of abstraction and (conceptual) model that is needed for the effective operational management of a system of services, which is pretty much what software is and has always been to some extent. The concept of a managed service is all but absent here, as are the standard set of signals one could easily imagine being captured in observing the service interactions.

At the other end of the scale, we have the yesteryear generic data-centric approaches being dragged kicking and screaming into the modern world of software microservices architecture and the observability requirements that come with it. Again common service level management concepts such as Service, Signal, and Status, are amiss here wholly. Instead, the instrumentation library interfaces consist of calls to start and stop a Trace or Span, increment and decrement a Counter, or log a LogRecord to a Logger.

OpenSignals for Services, on the other hand, strikes the perfect balance between these two extreme views of observability. Its model is specifically designed for service level management needs with the introduction of a set of fifteen Signal values and five Status values that can be fired by and associated with a Service, respectively. The domain is not the business. The domain is not the data. The domain is the system of services and the interactions that take place. Here methods on the Service interface capture what is essential to observability, including start, stop, call, fail, succeed, recourse, retry, reject, elapse, drop, delay, etc.