Applied Domain Driven Design Applied Domain Driven Design on legacy code on legacy code Khaled Souf twitter: @khaledsouf 1

About Me About Me more details on : https://ksouf.com 2

What is a legacy code? 3

"A code without a test." -- Michael C. Feathers (Author of working effectively with legacy code) 4

5

We are talking about lost knowledge. We are talking about lost knowledge. How the code works (actually). How the code should work (how it is expected to work). 6

Somebody knows the history of all that code!!! 7

Event storming to the rescue Event storming to the rescue 8

Event storming: How it works? Event storming: How it works? Gather the right people in the same room (those who ask the questions and those who have the answer) Provide unlimited modeling space Explore the domain starting from Domain Events 9

Look up/out for these people (Anti-Patterns) Look up/out for these people (Anti-Patterns) Dungeon Master Existing System Expert 10

Who is the Dungeon Master? Who is the Dungeon Master? "The Dungeon Master is the author of the original software, that used to support the business in the early days... in facts he knows the software better than anyone else. Even if he’s not any more a software developer, he’s still at close distance from its creation." -- Alberto Brandolino (Inventor of Event Storming) 11

Dungeon Master Dungeon Master Do Mob/Pair programming with him with one Exceptional rule: the Dungeon Master should have less the keyboard than others. Try to do some scratch refactoring "Lean to the compiler" 12

Who is the Existing System Expert? Who is the Existing System Expert? Thinks that he master the Domain but actually he is an expert of the existing legacy system Can be a QA Engineer, a User and even the Product Owner 13

Existing System Expert Existing System Expert Ask them to run a global demo of the system How they test the application (maybe you can have an nice surprise as an end to end automated tests already implemented) 14

Try to get the history of the system. Try to get the history of the system. Identify deprecated features. Figure out the "hidden features" (if there is). Check if there is a shift of the core domain (usually there is). 15

Now we have enough confidence to take a decision. Now we have enough confidence to take a decision. Based on my experience, we have three choices based on our understanding of the legacy system. 16

Low level of confidence. Low level of confidence. We expose our legacy system/code as a service (as an api for example). Use the Open Host Service (OHS) pattern to publish legacy features on a simpler way that it is. Create bubble context as new feature is needed. 17

Low level of confidence. Low level of confidence. 18

Medium Level of confidence. Medium Level of confidence. Create bubble context as new feature is needed. Every bubble context has its own way to ask information from legacy using Anti Corruption Layer (ACL) pattern on the use case service level. 19

Medium Levelof confidence. Medium Levelof confidence. 20

High Level of confidence. High Level of confidence. Create bubble context as new feature is asked or bug fixed is asked. If it is a bug fix refactor and extract the feature on new bubble context. Every bubble context has is own way to ask information from legacy using ACL's calling low level services. 21

High Level of confidence. High Level of confidence. 22

Warp-up Warp-up take an action only if there is an opportunity. Try to understand how the Legacy system works using event storming and Mob/Pair programing. Work wisely with the Dungeon Master and the Existing System Expert(They can be harmful to the legacy system). Sometimes your level of confidence can be different in every slice of the system: combine all the patterns used before (Legacy as Service, OHS, ACL, ...) 23

Thank you for attending Thank you for attending Questions ? website: https://ksouf.com 24