Leveraging Clean Architecture for Migration to Camunda 8

[lwluc]

This pull request shows of using clean architecture and DDD to keep you domain clean, so a migration, e.g. to Camunda 8 only effects your adapter layer.

Deep Dive 🤿
If you want to dive a bit deeper into the architecture have a look at the README or watch my talk at the CamundaCon2022.

What makes a migration difficult?

From time to time our framework usage, our interaction with the Camunda Platform, maybe spread over all layers (of a classical multi layer architecture e.g.). So maybe a bit of RuntimeService at the Controller, a bit of Task / History Service on the Service Layer and even some variable checking or update on our repository layer.

So for a migration we need to touch all layers, which would make a migration time consuming and stressful.
Because imagine you are standing in front of a chaotic, not sorted fruit counter and you have to pick out all the apples. Picking all the apples up will be stressful and time consuming and that metaphor reflect the difficulties of a migration perfectly.

But migration should not mean throwing away our old code base and doing it completely new.

Instead it should mean:

• Keeping our business representative code stable.
• Our objects and rules representing our business do not change with a framework.
• They are independent

Let your architecture support you on your migration journey

What you want are local isolated changes in a predefined specific location of the application. Not changes all over the place.

And that is what this repository especially this pull request shows: How our code base could be migrated with less invasive changes using the help of clean architecture!

Spoiler: It only focuses on code-related migration.
It do not focus on migrating our deployment, operations or other changes which may be followed by a migration.

[berndruecker]

Great example and blog post @lwluc - kudos!