The Black Box Perspective
When you have a solution comprised of collaborating components (services), it is easier to understand the solution if you are able to view each component as a black box and not have to worry about what is inside. To do this, you need to be able to characterize two things: (1) the observable dependencies of the black box—the components in its environment upon which it depends, including their interfaces and behaviors, and (2) the observable behavior of the black box—how it responds to stimuli provided by other solution components and which stimuli it provides to those components. That’s what this chapter is about.
There is a strong analogy here to the way in which people learn about things in their environment. When presented with an object they want to learn about, people are inclined to pick it up, turn it at different angles, and experiment with different ways in which they can interact with it. On electronic gadgets they press the keys, flip the switches, and touch the screen, all the while observing both the dependencies and the resultant behavior. They are making observations about the object.
You can think about solution components the same way, only the observations you make are not visual. The other components upon which they rely for proper operation characterize their dependencies, and the stimuli are the invocations of interface operations and other events that trigger component responses. Observations are the responses, such as returned data structures and the invocations of other component’s interfaces. What you learn about the component are its dependencies and observable behavior.
Of course, experimenting with a component to learn its dependencies and behaviors is likely to be a time-consuming and error-prone activity. Preferably you would like to have someone tell you how the component will behave and the components upon which it depends for proper operation. Such a characterization of dependency and behavior forms the core of the component’s specification.