Service linking
Learn the concept of service linking and the steps for doing this in Uniscale.
Introduction
This article assumes that you have covered knowledge around Specification and concepts in Service basics.
Service linking allows you to define a service outside-in. It gives you the possibility to first define the requirements that the defined functionality has for the specified service before diving into the details of how to model the service.
Having a look at the following illustration, we recognize the specification elements, and individually the Services on the side of it. Within the solution, there are UX flows that require functionality from the service and as such, it will be provided via Use case flows from the service.
What | Define the requirements for all technical functionality needed to build the intended user experience.
|
Why | Ensure a sustainable product architecture with low technical debt and an optimized services dependency for better ownership distribution. |
Who | Software architect or Tech Lead |
Outcome | Having each UX flow linked to a service draft that is ready to be further described and modeled. |
How |
Tutorial: Service linking
In this process, you will invite the individual responsible for the overall technical service or solution architecture. This step is crucial as it involves the initial architecture of splitting up the functionality.
Distribute your service functionality appropriately within your application. Many companies and projects often complicate this process, resulting in a "dependency spider web" or "ball of mud." This usually happens due to a lack of oversight on dependencies and the absence of deliberate decision
Linking to services from solution specification
UX flows act as the lowest level of detail you have towards the end-user behavior. They can either just describe plain end-user behavior but this is also where you define or link in the service flows that are needed to implement the use case.
After being linked, the UX flow will show under the linked Service flow. With that, we mean inside the Service linking tab, which will be explained below.
Navigate to Service linking
Please note that you will have to navigate to a module to see the "Service linking" tab.
Create service draft
You do so via the button to the right, and within the new card also create a namespace structure where the intended use case flows will be placed.
Link service flows
You can now link your service flows to your service drafts. This can be done in two ways:
From the left menu bar, you can drag each
Export your service draft
Once you have processed your use case flows, you can now "distribute", and create your services, along the nested namespaces and use case flows.
This will:
create new Use case flows if they never existed prior.
create new namespaces and place the Use case flows under them.
link existing Use case flows to the UX flows in the specification.
This change is irreversible so make sure you do this once all your specification breakdown has happened.
Service editor functional view
Inside the service editor of a solution-owned service, the tab "Functional view" will now be active.
Here, a filtered representation of the solution specification is shown with only the items that link to the service. In essence, it acts as an overview of all the dependencies the service has for the solution.
Next steps
The next step in this process is to review the technical modeling of your use case flows, enrich them with endpoints, and model their payloads. This is a quite complex task but we have plenty of guides to go through each step.
If you haven't done so:
Cover the Service basics
Familiarize yourself with Upstream & downstream dependencies
Lastly, proceed to Service revisions
This should get you covered through your first revision and thus completing your first service documentation!
Last updated
