This article highlights the importance of Service First Design – that is, designing the service straight after drafting the user interface for applications with a mobile or web front-end and a microservices back-end.
The traditional approach to application development is to first draft the user interface, then model the database and formulate the business rules to arrive at the finished application.
The Service First Design approach is to first draft the user interface, then design the service, then model the database and formulate the business rules to arrive at the finished application. The business rules and the data model are driven by the services required.
Also, implementation-wise, we should first create the screens and the services. The services can be created using a mock server at prototyping stage. This way, we can show the user a prototype of the application without creating an expensive back-end logic and database model.
Service First Design has the following advantages:
Independent development and testing
To ensure that both the front-end and server applications work as they should, it’s a great advantage to be able to run them independently. If the web APIs are clearly defined, mock-ups for both the front-end and the server can be created, enabling independent development.
Changes in the front-end specifications can result in changes to the web API. This can be relatively expensive if both the front-end and back-end need updating, as development, testing and deployment will all need to be re-done. Design and implementation of the web API first will keep this to a minimum.
- Different Teams
It might be that the front-end is developed by a different team than the back-end. This requires a solid definition of the web API end points before development has started. This way the front-end team can develop independently once the back-end service mock-ups are created.
Software development process
Using the Service First Design approach, the software development process would be:
Specify a feature of the application
Each specific feature of the application would be defined with the users and other stakeholders. This would result in screen layouts and flow of that feature. The screen would define the required data and services for this feature.
Design the service interface
Once the data required for a feature is known, the service interfaces can be designed. This would require the following steps:
- Determine the data model for the service
- Determine the type of service (Put/Get/Post) etc.
- Determine the “grouping” of services into business domains and controllers
At this point you will be able to:
- Document the API in tools like Swagger. Swagger can then also be used to generate code, both for the front-end and the back-end.
- Data models classes for both the server and the client can now be generated by tools like swagger
- Create mock-ups for the API (also using tools like Swagger).
This will allow the front-end developers to start creating screens without a full implementation of the back-end. End user feedback can be used to refine the screens and/or the services used. In other words, the design of services for a feature is an iterative process. As we are using the mock-up services, this can be done quickly and before we write any server code.
Once the definition of the service is deemed stable, the back-end design can commence.
Once the services are designed, we can start on the design of the back-end. This would require the following steps:
- Determine the database model and the type of database used (relational or otherwise)
- Determine the external services required
- Determine the business rules for the service
Grouping of microservices
Special attention should be given to the “grouping” of services into components.
Components can be replaced independently and upgraded/versioned independent of each other.
Different components can run on different servers or even different platforms.
It is common for a component to run in a self-contained “container” such as a docker.
The services in a component are dependant in that a change or an upgrade of a single service in the component requires an update of all the services in that component.
In the case of .NET, they make up a single DLL, and a change of a service in the DLL requires an update of the DLL.
Comments are welcome!
Please let me know if you want a practical example. I will post an article to illustrate the Service First Design using Angular/.NET