Service linking
Learn the concept of service linking and the steps for doing this in Uniscale.
Last updated
Learn the concept of service linking and the steps for doing this in Uniscale.
Last updated
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.
Identify what functionality you would need from services to be able to implement this user experience
Define the initial architecture for your services.
Define your services' boundaries.
Outline how the services will interact with one another.
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
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
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.
Please note that you will have to navigate to a module to see the "Service linking" tab.
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.
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
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.
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.
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!
