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 in 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 for a function, service can accept data as input and can produce data as output, both being described using data object artifact. For more details, refer to the function template.

Realization

From the service consumer's perspective, it is ok to look at it as a black box, but there must also be somebody 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 other way.