Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Applied Domain Driven Design on legacy code

Applied Domain Driven Design on legacy code

you'd like to apply domain driven to your old code ? you don't know how ? this talk is for you. i'll introduce few techniques and heuristics based on my experience dealing with legacy code and applying domain driven design concepts on it.

Khaled Souf

April 01, 2020
Tweet

More Decks by Khaled Souf

Other Decks in Technology

Transcript

  1. Applied Domain Driven Design Applied Domain Driven Design on legacy

    code on legacy code Khaled Souf twitter: @khaledsouf 1
  2. "A code without a test." -- Michael C. Feathers (Author

    of working effectively with legacy code) 4
  3. 5

  4. 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
  5. 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
  6. Look up/out for these people (Anti-Patterns) Look up/out for these

    people (Anti-Patterns) Dungeon Master Existing System Expert 10
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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