Service

A service is defined by its purpose and contract (input and output), so the documentation should clearly state what value it provides to the caller, what data needs to be provided as input, and what output it produces. Internal workings are typically not included because services are usually not under the governance of the caller. Hence, the only way to learn what the service does is from the documentation. The description should be business-oriented, focusing on what the service provides and what its goal is. It should not state what data structures it manipulates or what other systems it calls:

Input and Output

As with a function, a service can accept data as input and can produce data as output, both being described using a data object artifact. For more details, refer to the function template.

Realization

From the service consumer's perspective, it is okay to view it as a black box, but there must also be someone responsible for the development and support of the service who needs to know the internal workings. In the example above, the realization is described by the underlying function, but it could also be specified by a diagram or another method.