Henning Schwentner: Domain-Driven Transformation

In this talk, Henning discusses domain-driven transformations, focusing on how to effectively modernize legacy software systems. He emphasizes the importance of recognizing the inherent value in aging monolithic systems and illustrates the journey of transformation through the use of storytelling, particularly highlighting a case study involving a legacy auto leasing software. The speaker outlines the various 'diseases' often found in legacy systems, such as lack of structure and mixed domain logic, and presents strategic and tactical approaches to refactoring towards a more modular architecture. He advocates for a collaborative modeling approach involving both technical and domain experts, ultimately aiming to align the software architecture with business needs. Henning also stresses the necessity of soft organizational changes alongside technical transformations to ensure successful implementation of new practices.

[Music] yeah welcome back everyone I'm your host for this session I'm floan rle and uh I'm with me here with Henrik who is uh also a coach and a consultant um working at WPS Solutions and uh he will also give us today a very nice introduction and uh I think some very useful insights into domain driven Transformations um to actually uh yeah bring some architecture back to

Legacy monoliths a topic that I also find very interesting so how are you I'm fine although I had to do some last minute changes my my daughter is sick so I had to stay in the home office that's why you see there's some balloons here and I couldn't change the the decoration I hope she about the new work right yeah that's right that's right so for us

here um vacation just started so my daughters are at home too but uh that's not the only reason why I'm doing home office today day but it seems like we all back at our home offices so um all good here great so uh can you give us already some some let's say teasers what you will talk about in your in your talk yeah Flo you mentioned it

um we are going to transform existing software Legacy software um um and that's uh If we're honest uh the case that most of us are working and most of us are not working on a Green Field building new softare and even if we are next year or in two years we will be in the brown field we will work on Legacy software so it's I think for

every um developer important to know what to do um if we work with systems that are already there and we're going to see here how we can bring back architecture structure into those systems nice nice very interesting so I'm already quite excited and that's when you get the playing field so the Stag is all your okay Flo thank you very much and also welcome from my side

to this talk to main driven transformation good morning um I would like to tell you a little story for starters so when I was a little boy My grandmother used to take me by the hand and take me down to the port and there she showed me the big ships the big Steamers that came in and out of the port and she showed me also the big

old Warehouse where already her father my great-grandfather had traded cocoa and coffee and when my great grandfather had opened his window he could smell the Big Wide World could smell ripening bananas roasting coffee sometimes even wild animals and back in his days um the ships well they were unloaded by a man who literally carried cargo on their backs from the ship into warehouses into warehouses like this

here and well then uh the container was invented and the times changed forever just like um couple of decades later for us the container was invented and uh changed times forever but here I'm not talking about Docker when I talk about containers here I mean these big Steel in boxes um that changed seaf fairing and when you look closely you can see that these old warehouses um

where um the men carried the cargo in the old days well they were abandoned and you can see the Decay here and there's graffity there and so a big part of the harbor was abandon for a long time and these warehouses they yeah they became old and at some point um the Senate of the city said well um let's do something with this old area of the

harbor that let's build something new out of it so a plan was made and said well let's take this old warehouse and build a concert hall on top of it and well then they started construction and they well demolished the core the inside of the old building but they that the Ws outside stand and then here you can see the concert hall and a hotel was built

on top of that and it took years and years literally and eventually it was done and and then there was a big party um to be honest 10 years later than planned and 10 times more expensive than planned but now there it is in my hometown in Hamburg in Germany you can see this new concert hall the ELD Hony here and now again the world the big

white World um is coming back to the old warehouse now it's singers from Ukraine musicians from China and tourists from Australia and America coming to the old Warehouse again and what we did with the old Warehouse or what was done with the old Warehouse that's what we want to do with the old software as well we want to take something old and monolithic keep the nice Parts

the beautiful parts and build something new and useful out of this old stuff again and that's what I'm going to talk about for the next 45 minutes and who am I my name is Henning schent now you already heard that I'm known as the guy with the many kids in the community and I work as a coder coach and consultant at a company called WPS and this

topic of transforming old Legacy systems um that takes me so much that I've just published a book on that you can see that on the right here transformation um that is the book to The Talk The English edition um is just going to print um a German Edition is already out there and my other book is domain storytelling and storytelling um I would like to tell you

another story now a story about software a story about a company that has a big old Legacy Software System in place and wants to transform it that company is called ipon autoing Inc and guess what they do they doing auto leasing what's autoing well if you want to have a new car usually you have to give a big bag of money to a car manufacturer then the

car manufacturer gives you a car if you don't have a big bag of money well that's the point where the leasing company in our case iorn comes in between and uh the leing company will now pay the price give the big bag of money to the car manufacturer the car manufact urer will give the car to the End customer and the End customer will then um make

a monthly payment the so-called installment to the leasing company to Alor and I think we can all well imagine that there is sorry we can all well imagine that there is a big old Legacy S in Place which is called monol obiously and mon is 25 years old built in the technology that was on Vogue back in the day um around the start of the New Millennium

and if we take a closer look um in a c4 context diagram we can see here monol um is a system that is used um sorry monol you can see that here that is used by the salesperson and the risk manager and not the customer itself the customer they are closing a leasing contract with a salesperson and then the salesperson is using the system and the risk

manager is also using the system so monol is a bit like this ship here it was beautiful back in the day today it looks a bit well oldfashioned and also well it looks kind of used um nonetheless the boss of ipon says well dear it Department please modernize our old system and I think he's doing um something important here he's not saying throw this Old Rag of

a ship away no he sees that there's something important something valuable inside of this old Legacy software there's a treasure inside here a treasure of domain knowledge and it's worth to get this Treasure of domain knowledge out of the old system that's a good idea that's the first thing that you have to learn when you work with Legacy systems when you work with old systems that you

have to change your mind from this guy here who thinks oh my God I help hate this old mess to well this system has earned our um our company a lot of money for decades so this system did its job well that's the reason why it became so old all the other systems that were build in the 25 years that didn't do their job well well these

systems they are not there anymore we don't have to worry about them but we have to worry about the systems that did their job well and why did they do their job well because they supported the work of their users and the users the people from The Domain that's what we care about we want to support their own work and to get this treasure out of the

old system the first thing to do is we have to find out what is the problem of our system so if we think about our system um as a patient then we have to first find out we as doctors what are the dis diseases that our patient suffers from and that's important because different diseases they require different treatment right and what are the typical disease dises that

we can find in a legacy system so one typical disease that we find is that the old system has become a big ball of mud that means there is no structure in it everything is connected to everything else and especially for us important today is there is no vertical structure inside the system then the second disease that we often find is that the Cod has only poorly

expressed the domain knowledge that means um The Domain code and the technical code they are mixed up um there might be an damic domain model um there might be no domain language in the code if we look at a line of code it's not clear is this business logic or is this technical logic um that is all problematic that's also disease that we want to heal here

and then the third disease that we often find is the bad organization or the unfitting team organization um for a monolithic software a monolithic team might be okay or layer teams might be okay now where we want to transform into a more vertical structure we need also vertical teams here okay so what are we going to do about this well um in our book Kola and I

say well there's for all these diseases there's strategic transformation against the big ball of mud there is tactical transformation against um the poly expressed domain knowledge and there is team organizational transformation against the B Team organization transformation that's something big we need smaller steps that we can take and that's why there are refactorings defined that can help us here for the Strategic transformation we have strategic refactorings

still something big that we have to split up into tactical refactorings tactical refactorings that help us um strengthen the domain knowledge in the code um then there's socio technical refactorings for the team organizational transformation and there are tactical refactorings against model anemia um in the Tactical transformation of course we only have 45 minutes today so we cannot look at all these refactorings if you want to have

a a detailed look please have a look at the catalog that I um collect on my website domain D refactor here and one second please sorry okay so that is the catalog there you can find the catalog of refactorings um we will focus today on the Strategic part because that is the part that most teams that I work with um have the biggest problems and strategic transformation

what is that about well that is fighting mud this thing here um we want to bring order to it and so you can see here we want to transform it into vertical units smaller units um we want to come from the big bot of mud to what's called bounded contexts or microservices in some way so and what you can see here is um it's just four steps

that we have to take and well just for steps of course these steps they have big steps and they take long of time and they are complicated and also it's not like waterfall these steps it's itative incremental we have to run through these steps again and again but these steps having these steps can help us get the idea of how we can get a grip of the

old system and the first step is we have to put the monolith aside we have to ReDiscover the domain knowledge we understand what's really the problem that we are solving with our solution with that knowledge the regained knowledge of the the domain we can then move on to the second step and that is modeling the target architecture so with the knowledge that we have today what would

be the ideal architecture that we would want to build then the third step we get out the monolith and we see what is the current architecture and well from the current architecture to the Target architecture which is the way what is the direction that we have to take and the fourth step is we want to do the move and let's have a closer look at these four

steps um the first step the domain rediscovery what is that about so what might be counterintuitive but what is important is that the first thing we have to do when we want to split a monolithic piece of software is that we have to first put that old monolithic software aside that we have to move on from the brown field that we are working on move on to

a mental Green Field so we have to cleanse our mind from the solution that we already have and focus on the problem again because the solution that we have well it might fit the problem from yesterday or maybe it was never the perfect solution we have to re understand what the problem really is we have to understand what's there in the domain so again we have to

do a mindset switch and we have to move on from thinking about technology from just being programmers um to we think about the business we are programmers and business enablers well it's not about software um as an end in itself it is using software as a means to an end and that is that end is we want to be able to support the work of our users

of our domain experts so we have to move move on from thinking about the tooth Wheels to thinking about the dolls here and how can we do that how can we understand the domain ReDiscover the domain that's where collaborative modeling comes into play collaborative modeling is a a family of methods and um those methods are lightweight one famous example is event storming that's done with sticky notes

or another um collaborative modeling method is domain storytelling that's with stick figures and arrows so lightweight um because we want to have tools that can be easily understood by our users it's called collaborative modeling because we want to model together Us and Them us technical people and them um domain experts people that are using software and and in our example at alorn that means we will invite

the business people the domain people into a workshop we will invite a saes person we will invite a customer we will invite a risk manager and let them tell their story understand what they are doing and then the customer starts and tells us well the first thing I do is I tell my wish for a car to the salesperson and the salesperson tells us well I calculate

the installment for the contract installment we ask what's what does that mean a word that we don't know yeah the salesp person tells us installment that's the monthly payment that the customer has to make and let's assume the customer can afford that installment then the customer will sign the contract for the salesperson and then the salesperson will pass on that contract to the risk manager the risk

manager will check the credit rating that is the risk of the customer the risk manager calculates the resay value that is the risk of the car and based on the credit rating check and the calculation of the resale value the risk manager votes the contract to vote means say yes we want to do this contract or no the risk is too high for this contract we can't

do let's assume the risk manager votes positively votes yes then the salesp person can give the car customer so what you can see here is called a domain story from domain storytelling the idea is we let our domain experts tell their story those domain storytelling and while they domain experts are telling their story We record that story an a graphical notation so we draw a diagram and

thus we can reflect our users that is this is what I have understood did I get you right and then my domain experts can say yeah you got me right or no we have to change this a b when you think about the story that we can see here that's interesting we see many words from the domain we see many leasing words but no tech technical words

and that is good as I said we want to reand The Domain you want to re understand the problem not focus on the solution if you want to know more about about this special technique domain storytelling then please read my book on the top of domain storytelling or if you're generally interested in these kinds of methods um the KO Camp that's the yearly unconference on that topic

was just two weeks ago but it will happen again next year also beginning of May so with this step number one re understanding the domain we can now move on to step number two determining the architecture and that means especially finding the vertical architecture and this we do by drawing boundaries so in our domain story we draw boundaries by saying or by asking which activities Belong Together

from the perspective of the actors what are actors when we go to back to our domain story you can see these stick figures those are the actors and then we have the work objects here the car the contract and then we have the arrows those are called activities like here give or sign or tell those are the simple elements of a domain story so we discussed with

our users here where are boundaries which activities belong together and then we learn well the activities 1 2 3 and eight they belong belong together and they form what we call a subdomain subdomain is a part of the whole domain and this subdomain is called sales and then we learn the steps five six and seven they form another area another subdomain here which is called assessment and

with this knowledge that we can split up our domain into subdomains we develop our idea of the target architecture of the system because now we say well let's put this into another diagram a context map where we have one context sales and another context risk assessment or one module sales another module risk assessment so we will not build a monolithic system anymore we will now build a

modular system and two modules we just found will be called sales and risk assessment so what we are doing is we are using the domain knowledge to drive our architecture that's why it's called domain driven design or what are we doing here domain driven architecture because the domain knowledge drives our architecture drives our design and of course in real life there will be more than two modules

that we can find here um if you know about these um DDD words DDD domain driv design then the things that we found here these modules um they will be called um bounded contexts in the DVD speech okay um with this idea of the target architecture with this idea this is where we want to go we can then see well where are we now so let's align

the current architecture with the target and to determine the current architecture we need the source code of the system of course and the developers will tell us um how the architecture is and usually it's a good idea to have an architecture analyst to get an understanding of that and maybe this architecture analyst will use an analysis tool can do it manually often it's a better idea to

use it too if you want to have a deeper look into these tools then I can recommend you this book here by my co-author Kaa sustainable architecture so in our case at alorn um we found out that we have this system here which is used by the salesperson and the risk manager this is a high level view of the system let's have a closer look at the

system when we go down from the context view to the containers view we will see that monol is built out of a front end a back end database and you can see well as I said um it's built with a technology that were abog at that time the backend is ejb2 yeah um surface jsps well what's good about what we can see here is we apparently have

some sort of architecture we have layered architecture so the front end knows the back end the back end knows the database but not the other way around you can see these arrows here they point from the top to the bottom and that's good we have some structure here and when we go deeper when we go deeper um into the components view we can see the front end

is built from a leing surf and a partner Surf and the back end there's a calculator and a contract contract Service partner service again focusing on what's good here is we can see a lot of domain words we can see domain language or ubiquitous language as it's called DVD that's nice even the database tables have names from domain what's not so nice is that we can see

the language yes and we can see the horizontal architecture of the layers but there is no vertical structure there is no structure from top to bottom that's why we call there a big ball of mud right and wa a second okay so we have no vertical structuring here we have what's called a big ball of Muth and um what are we going to do about that well

first let's have a look where would we want to have our boundaries where would we um find that in the back end let's focus on the back end first because that's already enough so um we have these um bounded context we found these bounded context sales and risk assessment here and where do we find them inside of our backend so for one thing we would say well

sales we have that here oh wait a sorry folks for the interruption but uh modern software needs our assistance every day right and uh I hope Henry will be back uh will be back uh any second now um yeah in the meantime I would just keep talking to entertain you at least a little bit and uh um also maybe make a little bit of an advertisement here

um yeah he's awesome thanks F yeah all right so sorry um so um maybe I go back a slide again so where do we find the boundaries in this um system that we have already so when we bring the knowledge that we found um in our domain story together with with this architecture we can see well for sales we need the calculator and the contract servers and

the contract and the partner and for risk assessment we need the partner service and also the contract Service and the contract and the partner so we can see there are some parts which are easy to split like the calculator and the partner servers but what we also can see is there's a big overlap here in the middle and what are we doing about that well that's the

big problem when working with Legacy software right so what we would want to do is something like this right have one module one B context sales and another module another bonded context risk assessment but well wouldn't this mean that we would have a lot of duplication here and wouldn't that be bad well to find out if we really have a lot of duplication we have to go

a bit deeper so yeah we have this class contract here um but we have to go on a field and Method level to see if there's really duplication uh to be done here so what can we find on the classes contract Service and contract for example where do we find the boundaries of sales and there so um when we look into our analysis tool we can see

well the contract service has two methods sign contract and vote contract and it works on the class contract where we have a contract number and a signature date and accredit rating and a voting result and all these P they have Getters and Setters but there is no real domain logic in the contract so on a s side known this is what's called an anemic domain model not

so nice but we will not do anything against the anemia the model now um we will first split this thing here up on the other hand what is maybe kind of nice is that we can see well here sign contract Bo contract those are names from the domain that is something that we found in our analysis of the already and when we apply the boundaries that we

found to this code we will find something like this so um in sales we will need a class contract Service in a class contract and we will need the signed contract logic um in the contract Service and in the class contract we will use the contract number and the signature date but there's also a lot of stuff that we do not need the vote contract method credit

rating result credit rating voting result we don't need that on the other hand what do we need for the risk assessment we both need a class contract Service and a class contract but you we need the vote contract logic um and the credit rating and the voting result and we also need number so when we think about this topic of duplication the real duplication is yeah we

need two classes contract Service and two classes contract that's not so bad um and we need the contract number which is no surprise because that's the identity of the contract here so if we throw out all the stuff that's unnecessary then we find something like here and there's not much duplication going on here and on the other hand we get two models which are much smaller so

this is the idea of our Target architecture and if you never have heard about DDD domain driven design and strategic design on the one hand or microservices on the one hand then this idea of having several classes which have the same name and represent the same thing that might feel awkward for you but um it's still might be a good idea here so if you have never

heard about that topic strategic design DDD there something that you want to read so we have different models here modeling the same thing smaller models and this is our goal architecture our Target architecture how can we get there yeah well that's where our refactorings come play and what is usually done is that at this point we write down the refactorings that have to be done or to

be honest we write down some of the refactorings that have to be done of course it's iterative it's incremental and many teams um that have a product backlog put beside that product backlog an improvement backlog where they collect the steps that have to be taken to make their system better so um the first strategic refactoring is extract sales and then another refactoring that we want to do

is extract the bounded context risk assessment those are big steps obviously how can we split them up into smaller steps by saying well that's have some tactical refactorings as well um that's extract specialized contract as one thing and extract a specialized contract Service as another thing and maybe we want to even split these refactorings up into even smaller refactorings what we need in the and are Sprint

ready refactorings those are refactorings that are small enough to fit into one Sprint if you're working with scum or small enough that they are smaller than the work in progress if you are working with Kine and with that we have a plan and with this first idea of a plan we go um to step number four doing the and the first step to doing the move is

um to plan our transformation into our Sprint so the next time we're uh sorry the next uh time we're planning a Sprint we not only take the product backlog we also take the Improvement backlog with the refactorings that we found and the Sprint backlog is now not only filled with user stories user stories that's something new where we build new business value new requirements but we also

reserve some baseline here in the Sprint backlog for the Improvement for the refactorings so you can see here um the techical refactorings 1.1 and 1.2 are planned in Sprint as well and the Strategic refactoring one as well and now we go into the Sprint and when the Sprint is done then the user stories and the Tactical refecting are done the Strategic because there is some stuff more

here that we need but we move on plan the next Sprint and then maybe also strategic refactoring is done and we move on again and so on and maybe eventually the Improvement backlog is empty or not of course in real life the Improvement bulog never gets empty because there's always new stuff that um will be added to the Improvement backlog of course there's a lot of technical

debt and probably there will will also be new technical depth with which will be built and this technical depth is something that we want to get rid of improvements so truth be told a transformation is not something that is done the transformation is something that is ongoing for the whole life cycle here okay that's the plan and when we look on how it is done let's look

at the code again so we have the old monolithic system monol and we want to curve out a new bounded context we want to curve out the risk assessment context and for risk assessment we know well this vote contract logic we need that and vote contract is called Somewhere in the code and vote contract on the other hand calls get Contract number and set credit rating and

set voting result on the hand so now we have to find the small steps that we can take and these small steps they should be viable steps we want to do the transformation in an evolutionary way that means every single step should lead to a system that is viable itself uh to A system that can be released and usually will be released to production so the first

step that we are going to do is we create an empty mod your risk assessment that's something that we could release to production and then we create an empty class contract Service that also could be release to production and then we copy the logic from vote contract from left to right that is from the monol monolith to the risk assessment bonded context and that means well both

contract calls get Contract number and set cred credit result and now we have a duplic which is not nice of course but we have something that is viable and that's the important thing here we can do this step by step the next thing is um do this year so change the implementation of vot contract on the left so that it um is just forwarding to boat contract

on the right again this is a viable evolutionary step and now we have many arrows in the middle which is not so nice we want boundaries there right um so the next thing is um that we um the the Cs of the old method of vote contract in Monas to vote contract in the contract Service and maybe this takes a long time because many places in the

code call V contract but also eventually will will be done we will have moved all the old CS of V contract to C through the new V contract and then we can get rid of the old V contract and that's the point in time where we start strangle the old system to strangle monolith that's the point where the mon starts to get smaller that's nice okay and

then of course we are doing something similar with the contract build an empty class here um move Fields over and then um use them here on that side so we can get rid of first Arrow here and then the credit rating the same stuff and the voting result um and then we can get rid of the credit rating here and we move also the voting result here

and we do this step by step and eventually we can get rid of more and more stuff in the old system and now we have only one Arrow left here in the middle and we we finally got some real boundaries here which is nice and now we did this only on the business logic layer we want to do that in the UI layer as well in the

database as well and that of course might be harder but still it is possible and that's the important lesson um when we throw the old stuff out of the monolith then we get something like this here which is um what would be the next steps when we have done this strategic transformation well that would be tactical transformation probably so we would look on the right side here

on the risk assessment and I already told you um anemic um is what we find here an anemic domain model anemic domain model means uh the domain data and the domain logic they are not encapsulated so we find all the domain logic the contract Service and all the fields all the data in the contract it means the class contract cannot ensure that the data is always correct

that it's not corrupted that um that that somebody that shouldn't do it brings it into a state which is um viable so that's where tactical transformation comes into play um and I'm sorry we don't have the time uh for that today um so I'm going to jump to the conclusion now um so what else is there so technical transformation I said yeah that's something that we want

to do anti-anemia refactorings for that soot technical transformation is also we want to do we found the vertical cuts for our system now we also have to change the teams and usually before we can can do all the stuff we have to do what's called technical transformation an old system and Legacy system might not be stable enough to do refactorings to it so maybe the first thing

we have to do to bring some bigger test coverage to it or to automate the the build to have um continuous integration to continuous deployment if we don't have the step some projects before we can do that we even have to first introduce Source control if we don't have these things well refactorings they are hard and um that as an Outlook um what can be done what

else can be done in the transformation and of course um when we have um a short talk about this topic it might feel a bit like in this old Meme here how to draw an owl um easy draw to circles that's step number one and step number two now draw the rest of the them all I hope I gave you an impression an idea of how steps

one a 1 b 1 C could work out and if you want to know all the details well then read my other book of course and uh with that said um I want you to take one lesson um that's important mono transformation is and it is hard so don't make the mistake to go on the journey alone and do all the mistakes yourself take someone with you

that already did most of the mistakes and doing some advertisement here um please consider making a blood donation I don't want to advertise for myself only also for doing something good right after the pandemic there's not enough blood in the blood banks yeah so please think about your blood and that's it the end and flow you turned on your camera again all right perfect so thanks for

the session we a little bit over time but still maybe we can take one or more questions uh in there and uh let me start with um the big topic of organizational changes because I mean domain driven is always very nice and works uh works on paper is maybe the wrong word because getting there is of course the hard part right and making it even work on

paper is quite often very challenging uh and this is of course this is all paperwork right anyway um but quite often of course and I mean I'm coming from the Micron and perspective very often the the hurdles are not let's say the technical aspects but very often an organizational one so what are your recommendations how can you introduce this kind of change and Paradigm Shift uh maybe

in a soft way to to have some transition and to bring it into to let it syn into the organization yeah so first it's important to see um that software is not just a technical system software is a socio technical system and the organization of the people um has a direct influence in the software architecture so this is um expressed in Conway's law right um we often

see that here Conway's law basically says um the team organization um that you choose for your teams will be reflected in the architecture um of your system and that means um that you have to be careful with layer teams for example this is something that I often find in Legacy systems that we say well um we bring all the experts together so we have a database team

and a business logic team and a presentation team and all the UI experts they are in the presentation end this is not of course not a micro front end this is the mcro front end the one big fronted for everything and one when we want to have vertical Cuts in the system it's important to see that we need vertical Cuts in the team also so what we

want to do is I show it again is this here from layer teams move onto cross functional teams and then all these teams here team a and Team B and team C they are cross functional that means for example they all build their own front end and that means they all have to know the front end expertise not the whole team but every teams need at least

one front-end expert so that's that's why we're talking about cross functional teams and then of course we have we're touching agile topics like we need um t-shaped skill profiling for the team members and so on and um what is important for the topic today is that um strategic transformation and socio technical transformation they always go hand in hand just because of Conway's law so you can cannot

do only um strategic transformation you have to reorganize a your people as well well you have to reorganize your teams as well awesome all right so thinking of time there are no more questions and we are already a little bit over thanks again Henning for the for the nice presentation and uh to your daughter get well soon and uh thank you have a nice rest of the

day everyone enjoy the conference Flo thank you very much thank bye for