Service linking: Advanced concepts
Learn best practices for how to structure your services.
Last updated
Learn best practices for how to structure your services.
Last updated
The service boundaries are governed through much of the same thinking as the module boundaries. As services just like modules are maintained through revisions, it is important that a single team has ownership of a service and that functionality that normally changes together is contained by a single service.
The reasoning is that you want to avoid shared ownership of a service as you then will quickly end up with projects/releases that are executed separately but are tightly coupled to each other and end up having to be released together anyway.
In Uniscale you do not necessarily have to think of a single service as a single source code or a hosted instance of a source code. Through the SDK you may work with monoliths containing multiple services in one hosted instance and a single service divided into multiple running source bases. This allows you to split your service based on functionality while still having the flexibility to scale and maintain a good, clean, and flexible technical architecture.
The way you define your service boundaries allows you to decide how you want to grow your organization in the future as the organization of functionality through module and service boundaries will impact the future structure of the organization maintaining them.
Through Uniscale you essentially have two ways of defining your service boundaries. One is the traditional inside-out where you define the functionality from within the services themselves. This can often lead to defining too much functionality and often also defining misaligned functionality. In Uniscale even this approach will lead to more accurate service boundary modeling as you will always start by defining your standalone and technical use case flows.
This forces you to define why you need the functionality ahead of defining the endpoints themselves. As a result, you are much more equipped to detect any bad service boundary definitions before it's too late.
The recommended way when using the functional specification in Uniscale is to model your service functionality through service linking. This means using the functional requirements to define what functionality is required from the services
Through this flow you will first go through all defined UX flows in your specification and define which ones require functionality from a service. If the functionality exists in the service from before, you can just go ahead and find it in the services tab in the left sidebar and drop it onto the UX flow.
However, if the functionality does not exist in a service yet, you define a service flow under the UX flow and write a short description of what it needs to do and what its technical acceptance criteria are. You will not decide at this point which service you want to have delivered this flow.
When you have gone through and mapped up all UX flows in the current module revision to existing or new service flows, it is time to move over to the Service Linking tab. The Service Linking tab allows you to map your newly defined service flows to any existing or new services while having the full perspective in mind.
This will allow you to see the larger picture as you split the functionality out between services potentially owned by multiple teams in your organization. This allows you already here to realize whether you will need to engage more than one team to implement the specified functionality and what impact that will have on your project.
Any new dragged or connected Service flows to a service will show up with a Blue accent, to indicate change. This is also reflected in the button label under each service.
Once all service flows have been connected to a service, the list will be empty.
You can enable to see the linked ones as well via the top filter. You are now ready to create any new services that you have designed and export the changes to any existing services. By exporting you will start a new revision of the service and prepare it will all the newly defined flows.
