Use Case Driven Microservices Architecture...

Communicating Process Architectures 2018 1 K. Chalmers, J.B. Pedersen et al. (Eds.) IOS Press, 2018 © 2018 The authors and IOS Press. All rights reserved.

Use Case Driven Microservices Architecture Design

Jeremy M. R. MARTIN and Peter J. BOGGIS Lloyd's, One Lime Street London, EC3M 7HA, UK

Abstract. We extend the Use Case Driven Object Modelling methodology to the decomposition of a system into microservices. We introduce the concept of the Aggregated Class Interaction Diagram as a tool for balancing the number and complexity of interfaces between services with the benefit of constructing a system as a set of simple, independent, single purpose components. This is illustrated with a practical example of a system for running stochastic financial models. Keywords. microservices, architecture, object modelling

Introduction

Microservices Architecture [1] is a modern flavour of Communicating Process Architecture, based on fine-grained services and lightweight protocols. It represents a fundamental shift in Solution Delivery practice away from building complex, multi-tiered monoliths. Its main principles are as follows:

1. A microservices-based IT system is delivered as a set of loosely coupled

components;

2. Each component service implements one specific capability from an enterprise perspective;

3. Components can be independently developed, potentially harnessing different technologies as appropriate;

4. Communication uses technology agnostic protocols [2] (i.e., the design is not dependent on specific communications infrastructure and can be implemented anywhere);

5. Microservices are small in size so that they are suitable for implementation and support by a DevOps team with a continuous delivery software development mind-set.

There are certain similarities with Service Oriented Architecture (SOA) [3]. However

the fundamental difference is that SOA is primarily used at an enterprise level for automating business processes by orchestrating IT services into workflows. Microservices are used for replacing the individual monolithic services with collections of simple, single-purpose, lightweight processes. For this reason Domain Driven Design is typically used for microservices while Process Driven Development [4] is employed for SOA.

CPA 2018 preprint – the proceedings version will have other page numbers and may have minor differences.

2 J.M.R. Martin and P.J. Boggis / Use Case Driven Microservices Architecture Design

The Microservices movement has emerged from the DevOps1 culture and this approach can provide a great deal of flexibility to DevOps teams. Addressing business requirements by adding or modifying microservices is potentially much more agile and cost-effective than diving in ‘under the hood’ of legacy monoliths. However, without careful design, there are some serious complications that could be accidentally introduced with this approach. For instance:

1. Domain ‘bleeding’ across service boundaries results in excessively complex

and chatty interfaces;

2. Lack of business focus as services do not map to business capabilities;

3. Neglected standardisation as individual services diverge from supported technology roadmaps;

4. Deadlocks and race-conditions as ill-designed communication patterns lead to pathological concurrency bugs which are notoriously hard;

5. Nanoservices due to overzealous decomposition, as the number of interfaces between components may be proportional to the square of the number of components!

This paper is concerned with how to design microservices so as to produce well-balanced collections of loosely-coupled processes. We start with the Use Case Driven Object Modelling methodology [5] which provides a systematic, step-by-step approach for converting business analysis outputs into working code. This is particularly suitable for delivering monolithic systems – however we shall add an additional step to guide the decomposition of an object-oriented model into well-designed microservices.

The main steps of the use case driven approach are as follows. Glossary. A glossary of terms is produced in business language to define the

business entities clearly and so provide a shared vocabulary between the customers of the system and the technical team.

Domain Modelling. The glossary is converted to a domain model diagram which represents the entities and the relationships between them. Three types of relationship are shown: inheritance, ownership and association (which may be one-to-one, many-to-one or many-to-many).

Use Case Modelling. The use cases for the system are elucidated and, in particular, how the users will work with the system to be delivered.2

Robustness Analysis. Following the Use Case Modelling, the domain model is revisited to address any gaps that have emerged, such as missed business entities or ‘boundary’ entities (which may either be user interfaces or other IT systems).

Sequence Diagrams. The use cases are converted into sequence diagrams which show the tasks to be performed by the various components of the system to be delivered, that are in one-to-one correspondence with the entities of the domain model, and the order of these tasks and their interactions.

1 DevOps is a software engineering culture and practice that aims at unifying software development and software operation. 2 Techniques for constructing uses cases, such as Behaviour Driven Development, are outside the scope of this paper.


J.M.R. Martin and P.J. Boggis / Use Case Driven Microservices Architecture Design 3

There are further steps in the process which are used to derive the code logic, but these are outside the scope of this paper which concentrates on design. Once the steps above have been completed we will have constructed a development blueprint which consists of an object oriented domain model with boundary entities inserted, together with an understanding of the functions that will need to be implemented for each class and how they interact with each other. The missing step that we intend to address is how to partition this set of classes into an effective collection of microservices which wrap these entities and establish bounded contexts.

Use case analysis can provide insights into interaction hotspots and the Aggregated Class Interaction Diagram, which we will later describe (henceforth referred to as ACID), provides the development team with a visual tool for selecting a healthy microservices design.

1. Worked Example: Stochastic Model Runner

We consider the design of a system for managing financial models developed by actuaries to simulate a year of business in the London Insurance Market. These models are developed using a domain-specific high performance programming language and are executed across multiple parallel computers on a computational grid. The purpose of this work is for determining the appropriate size of various capital funds to adhere to the Solvency II regulations [6]. Essentially this is to ensure that there will be enough money to pay out on all insurance claims, whatever the market conditions, at least 99.5% of the time.

We start by constructing the glossary. Recall that this should define a domain-specific vocabulary to be shared between the customers and the technical team that is used throughout the analysis and design process.3

(Stochastic) Model: a program developed by actuaries which reads an input dataset, calculates a projection which is based on a set of random values, and then writes out a results dataset.

Data Item: a multidimensional table of data values at specific coordinates

Dataset: a collection of data items.

Input Dataset: a dataset of financial market data that will he processed by a model.

Results Dataset: a dataset resulting from a model run.

Grid: a collection of computers used to run models together with a device for storing model results.

Model Run: the action of running a model on the grid with a specific input dataset.

Scheduler: a software tool which manages the grid and the schedule for model runs.

Model Runner: the web portal that will be developed as the user interface to the system.

3 In this example the business language is somewhat technical because the business customers are actuaries.



Next we convert the glossary into a domain model (Figure 1) to illustrate the relationships between the components.

Figure 1. Domain model for Model Runner.

Then we describe a collection of named use cases. In each case the user is an actuary and the context is interaction with the model runner tool.

Register Model. The user chooses the register model option. The model runner displays two labelled data entry boxes. The user supplies a reference to the model code repository and a model name and presses the register button. The system validates the user’s inputs and, if the validation passes, creates a new model entity.

Register Input Dataset. The user chooses the register input dataset option. The model runner displays two labelled data entry boxes. The user supplies a reference to the input data repository and a dataset name and presses the register button. The system validates the user’s inputs and, if the validation passes, creates a new input dataset entity.

Submit Model Run. The user chooses the submit model run option. The model runner displays a model selector widget and a dataset selector widget, prepopulated with all registered models and input datasets respectively. The user selects a model and dataset then presses the submit button. The system creates a model run and submits to the scheduler which will run the model on the grid which will create and store a results dataset in the persistent data store.

Retrieve Model Result Dataset. The user chooses the retrieve model result dataset option. The model runner displays a prepopulated model run selector widget. The user selects a particular model run and presses the retrieve button. The system checks the status of the model run with the scheduler. If it has successfully completed it displays a link to the results dataset. Otherwise it displays a report of the current status of the model run.



Now we move on to robustness analysis. We review the use case descriptions to find out whether there are any entities missing from the domain model that will need to be represented in the IT system to be delivered. We note that there are mentions of a model code repository and an input data repository, so both these entities will need to be added to the domain diagram. There is also a clear need for data persistence, for instance the system needs to store and retrieve registered model code and input datasets. So, for now, we also add a persistent data store to our model which is now as shown in Figure 2.

Figure 2. Extended domain model.

In the next stage, we start to specify the interface functions that will need to be provided by each class in order to implement the use cases by creating a sequence diagram for each one (see Figures 3-6).

This has now produced a development blueprint for a monolithic version of the Model Runner. However, in order to progress to designing a clean decomposition of the domain model into microservices, the next section introduces a representation of the domain entities with the sequence diagrams overlayed.



Figure 3. Sequence Diagram for Register Model.

Figure 4. Sequence Diagram for Register Input Dataset.



Figure 5. Sequence Diagram for Submit Model Run.

Figure 6. Sequence Diagram for Retrieve Model Result Dataset.



2. Aggregated Class Interaction Diagram (ACID)

To construct the ACID we build a graph where the vertices are the functions of each class in the domain model extracted from the sequence diagrams. Arcs between vertices represent calling relationships between classes. A putative domain decomposition may then be superimposed over the graph and the number of arcs which cross partition boundaries will provide some measure of the interface complexity of the corresponding collection of microservices to be balanced against any perceived benefits.

Recall that we want our microservices to be loosely-coupled, small and well balanced. We will consider:

1. The number of arcs between components to represent (inversely) the degree

of loose-coupling,

2. The number of vertices within each component to represent its size, and

3. The variance of the number of vertices within each component to represent the degree of balance in the system.

For the model runner the ACID is shown in Figure 7. The vertices are grouped into

clusters for each domain model class. They are shaded differently depending from which use case sequence diagram they emanate. So for the Model Runner class there are twelve vertices representing the functions from each of the four use cases. They are then linked by arcs to vertices which correspond to functions of the other classes with which they interact.

Figure 7. ACID for Model Runner

We want to apply a domain decomposition to split the set of classes into partitions so that each partition would be implemented as a separate microservice. For this to be worthwhile we would like to keep the number and complexity of interfaces between the microservices to a minimum, as maintaining interfaces is the bane of any IT Service Management Team. We would also like the microservices to be relatively small so that they



can be developed and supported in an agile manner, but not too small so as to avoid the pathological anti-pattern of nano-services.

The ACID shows clearly that our current design will be tricky to decompose into microservices. There are too many interfaces and trying to remove them by partitioning would only serve to produce an unbalanced set of services veering towards monoliths. For example, combining Model Runner, Model and Input Dataset into a service would remove six of the twenty interfaces, but that service would have to provide over half of the functions for the entire system.

To make the system more amenable to Microservices Architecture, let us consider refactoring certain elements of initial design. Firstly we consider what would happen if we removed the Persistent Data Store object and required instead all the clients of that class to manage their own data persistence (an approach known as Polyglot Persistence). The diagram would change to Figure 8.

Figure 8. ACID with Persistent Data Store removed.

This diagram now looks significantly leaner, with eight out of twenty interfaces having disappeared.4 However there is still a problem with a large number of interface connections to the Model Runner class. Another refactoring exercise to consider next would be to move most of the user interface functionality out of Model Runner and into classes Model, Input Dataset, and Model Run. Essentially the Model Runner component would handle the selection of the relevant use case, but the specific user interfaces for each use case would be managed by the appropriate domain class. This is shown in Figure 9.

We now have a design that can be split into microservices in a relatively clean fashion. The number of interfaces is greatly reduced and we have achieved a good domain-oriented focus. The eight remaining components could be delivered as eight loosely coupled and small microservices. Or if that level of granularity were considered too fine for the enterprise, they could be combined into a small number of capability-based services, as shown in Figure 10. 4 There would be some corresponding modifications to the sequence diagrams as well, but we omit these for the sake of conciseness.



Figure 9. ACID for Refactored Design with UI Functionality Delegated to Domain Classes.

Figure 10. Decomposition into services.

Figure 10 represents a set of domain-oriented aggregates with bounded contexts. The

diagram tells us that the degree of coupling between services is either 1 or 2, which is good. The component sizes are 4, 4, 4, and 7 which indicates that the services are small and also well-balanced. This has been achieved by making a couple of unexpected changes to the design.



3. Further Work

As mentioned in the introduction, there are complications that can arise from Microservices Architecture which may potentially detract from its value.

The current scoring of size, balance and loose coupling arising from the ACID visualisation is somewhat crude, since all interfaces and functions are treated as being equal. A further enhancement would be to weight the arcs and vertices of the graph according to complexity, perhaps small, medium and large, so as to get a more accurate appraisal.

Another concern is referential integrity of data. In a monolithic IT system, relationships between business entities and the transactions which affect them can be managed effectively by relational database systems. However distributing data over several services can make this more complicated. For instance in the Model Runner application we separated the persistent storage of model runs, models and input data sets. With many users working on the system concurrently there could be issues with inconsistent data commits across the systems. Fortunately this is a well understood problem that can be solved by a distributed two-phase lock and commit protocol [7] but would undoubtedly add to the complexity of implementation and likelihood of bugs and, if the scale of the system grows sufficiently large, to inefficient execution (with many back-offs and retries). There is potential for the approach of this paper to be extended to represent distributed transactions visually so as to aid design decisions where they might be important considerations. Alternatively, we could be satisfied that our set of microservices will be eventually consistent5 and so avoid the issue, however that approach does not suit every system

A further issue is to avoid potential communication issues in Microservices design, such as deadlocks and race conditions. The client server design pattern [8, 9] would seem to be a suitable paradigm to adopt, since it is easy to understand and to implement and also lends itself to building microservice architectures that can easily be modified or extended while still adhering to the pattern. The basic idea is that all communications are client-server and there must be no cycles of client-server relationships. This could be easily checked from the ACID graph by using directed arcs instead of undirected, to represent the client server orientation of interfaces between classes. Further work is required to evaluate this proposal in practice.

This paper has concentrated on top-down discovery of microservices, using domain decomposition. However microservices may sometimes emerge from the bottom up. As each problem space is explored and solved, a collection of useful pre-existing services will grow and be available for reuse in solving new problems. This may particularly be the case for cross-cutting concerns. It will be interesting to explore how or whether the methodology of this paper could be adapted to the conversion of legacy monolith systems to microservices, simultaneously reusing existing services where feasible, and providing good adherence to the architectural healthiness criteria that we have explained.

5 Eventual consistency is a property of a distributed system which informally guarantees that, as long as the value of a given data item has not changed, eventually all accesses to that item will return the last updated value. For example, if multiple users around the world queried an eventually consistent distributed catalogue to purchase goods simultaneously, then they might see different stock levels for items that had recently been restocked or purchased. However they should see the same stock levels for items where the inventory had not changed for a sufficiently long period of time. This could result in a potential race condition to the checkout!



4. Conclusions

We have shown how to extend the established Use Case Driven Object Modelling design methodology so that it is suitable for systematically designing microservices architecture. This was achieved by defining a new diagram, ACID, to help evaluate the merit of potential domain model decomposition strategies.

We presented a case study where we calculated an optimal architecture for a complex business problem which led to a somewhat unexpected and illuminating result. Our analysis has suggested that it is better for each microservice to handle all technical aspects of its domain, such as data persistence and generation of user interface elements, than to delegate the responsibilities to shared services.

This observation independently confirms that made in related work by Taibi et al. [10]. They documented a microservices design pattern which they called the Database-per-Service Pattern in which each microservice accesses its own private database. They reported six case studies where this pattern had been applied.

Finally, one anonymous reviewer commented that the idea of producing a design for microservices following an object-oriented approach of entity relationships and use cases seems strange. Would it not be simpler to bypass object-oriented design and go directly to microservices? Our response is that there certainly are different approaches one can take to microservices architecture. We like the Use Case Modelling and ACID approach because we often need to decompose existing systems which already follow an object-oriented paradigm, and, object-oriented design offers structural tools for dealing with abstraction, inheritance and polymorphism. Our approach gives us an angle for refactoring legacy systems. Alternatively, it would be straightforward to modify our domain modelling step to produce a set of communicating processes rather than a set of classes. This adjustment may even be preferred if the target development language supports internal concurrency and message passing. The rest of our method would essentially remain the same.

The views and opinions included in this paper belong to their authors and do not necessarily mirror the views and opinions of the Lloyd’s Corporation.

References

[1] Sam Newman. Building Microservices: Designing Fine-Grained Systems. O’Reilly ISBN: 978149195 0357. 2014.

[2] Leonard Richardson and Sam Ruby. RESTful Web Services. O’Reilly 2007. [3] T. Erl. Service-oriented architecture (SOA): concepts, technology, and design. Prentice Hall. 2005 [4] V. Stiehl. Process-Driven Applications with BPMN. Springer 2014. [5] Doug Rosenberg and Matt Stephens. Use Case Driven Object Modeling with UML – Theory and

Practice. Apress . ISBN-10: 1590597745. 2008. [6] European Insurance and Occupational Pensions Authority. Solvency II Directive.

https://eiopa.europa.eu/regulation-supervision/insurance/solvency-ii. 2009. [7] Jim Gray and Leslie Lamport. Consensus on Transaction Commit. Microsoft Technical Report, MSR-

TR-2003-96. 2004. [8] J. M. R. Martin and P. H. Welch. A Design Strategy for Deadlock-Free Concurrent Systems. Transputer

Communications, Vol. 3 (3), 1–18. John Wiley & Sons. 1997. [9] Jeremy Malcolm Randolph Martin. The Design and Construction of Deadlock Free Concurrent Systems.

DPhil Thesis. University of Buckingham. 1996. [10] Davide Taibi, Valentina Lenarduzzi and Claus Pahl. Architectural Patterns for Microservices: a

Systematic Mapping Study. 10.5220/0006798302210232. 2018.


Use Case Driven Microservices Architecture...

Documents

Transcript of Use Case Driven Microservices Architecture...