Beauty of #microservices: part 2 architecting for change

1 Introduction

This blogpost is inspired by several blogposts about microservices and it is based on the blogpost REF1 “Architecting #cloud-friendly application architecture #apparch (inspired by #microservices)” http://improving-bpm-systems.blogspot.ch/2015/04/architecting-cloud-friendly-application.html which uses other blogposts about microservices http://improving-bpm-systems.blogspot.ch/search/label/%23microservices

See the part 1 “Beauty of #microservices: part 1 #entarch #apparch” http://improving-bpm-systems.blogspot.ch/2015/05/beauty-of-microservices-part-1-entarch.html for the definition of the following terms: business process, orchestration, microservice or Autonomous Component (AC), and microservice architecture.

2 Review of two recent posts

Several articles about changeability of microservices-based solutions.

2.1 “Rotem Hermon on Change Driven Design” http://effectivesoftwaredesign.com/2015/05/12/rotem-hermon-on-change-driven-design/

START quote

In particular I like very much Rotem’s definition of the four principles of Change Driven Design:

1. Areas of change should be contained.

2. Things that are more likely to change should be easier to change.

3. Things that are less likely to change should not depend on things that are likely to change.

4. Change should entail extending the system rather than refactoring.

END quote

RE item 2: Many types of changes must be anticipated in the architecture and thus they are easy to do. Other changes must be possible. For example, [REF1] states that business-process-centric solutions have several types of artefacts: event, business-process, rule, role, activity, data, document, audit trail, and KPI. Their changes are anticipated and these artefacts are structured as shown below.

All artefacts are available as microservices – see below (only 4 lower layers are shown).

Techniques for composition of microservices: DSL (BPMN, DMN), interpretive general languages (Groovy), compiled generic languages (Java). Off-The-Shelf (OTS) microservices can be used as necessary, e.g. business process engine for BPMN.

RE item 4: Technical changes should be fused with business changes in accordance with the PDCA cycle.

• [Plan] measure how the work is done,
• [Plan] observe the business environment,
• [Plan] decide in what areas the solution should advance,
• [Do] implement the decisions taken,
• [Check] validate the effect of those decisions, and
• [Act] refactor some microservices to adopt internally the improvements.

2.2 Microservices – Sharpening the Focus https://genehughson.wordpress.com/2015/05/18/microservices-sharpening-the-focus/

RE “In short, the application architectural style known as microservice architecture (MSA), is unlikely to be an appropriate choice for the early stages of an application.”

On the contrary, at the early stages of solution elaboration as a functional prototype, a high rate of changes is mandatory thus microservices-based solutions offer a huge gain in development time.

RE “The moral of the story, at least in my opinion, is that intentional design concentrating on separation of concerns, loose coupling, and high cohesion is beneficial from the very start. Vertical (functional) slices, perhaps combined with layers (what I call “dicing”), can be used to achieve these ends. ”

Yes and [REF1] offers slicing and dicing out-of-the-box – vertical separation by business processes and horizontal layers as shown in illustrated above.


Thanks,
AS