Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Rebuilding Legacy Apps with Domain-Driven Design - Lessons learned

1,103 views

Published on

Talk delivered at Domain-Driven Design Exchange 2018

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Rebuilding Legacy Apps with Domain-Driven Design - Lessons learned

  1. 1. Rebuilding Legacy Apps with Domain-Driven Design1 1 Lessons learned
  2. 2. Kacper Gunia • Independent consultant at Domain Centric • Helping companies to be successful with DDD • @cakper / kacper@gunia.me
  3. 3. It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. — Joel Spolsky
  4. 4. Not all of a large system will be well designed — Eric Evans
  5. 5. Legacy strategies by Eric Evans 1. Bubble Context 2. Autonomous Bubble 3. Exposing Legacy assets as services 4. Event Streams
  6. 6. $ SET SOURCEFORMAT"FREE" IDENTIFICATION DIVISION. PROGRAM-ID. Iteration-If. AUTHOR. Michael Coughlan. DATA DIVISION. WORKING-STORAGE SECTION. 01 Num1 PIC 9 VALUE ZEROS. 01 Num2 PIC 9 VALUE ZEROS. 01 Result PIC 99 VALUE ZEROS. 01 Operator PIC X VALUE SPACE. PROCEDURE DIVISION. Calculator. PERFORM 3 TIMES DISPLAY "Enter First Number : " WITH NO ADVANCING ACCEPT Num1 DISPLAY "Enter Second Number : " WITH NO ADVANCING ACCEPT Num2 DISPLAY "Enter operator (+ or *) : " WITH NO ADVANCING ACCEPT Operator IF Operator = "+" THEN ADD Num1, Num2 GIVING Result END-IF IF Operator = "*" THEN MULTIPLY Num1 BY Num2 GIVING Result END-IF DISPLAY "Result is = ", Result END-PERFORM. STOP RUN.
  7. 7. Reasons to rebuild • Lack of expertise • Cost of maintenance is greater than cost of rebuild + maintenance • Change to a single component cascades through the system • Replacing off-the-shelf solution
  8. 8. Lessons Learned
  9. 9. Lesson 1: Context Map is your friend
  10. 10. Understand the big picture • Non trivial systems never live in isolation • Look for relationships and understand them well • Find boundaries • Look at cost of breaking / maintaining the relationship • Make sure you understand the scope well
  11. 11. Integration groundwork • Improve / change relationships that might be hard to maintain • Do not rebuild and change interfaces at the same time • Hedge contexts with Anti-Corruption Layers • Work out non-functional requirements • Make use of existing tests suites / write new • Automate parallel validation • Track progress
  12. 12. Lesson 2: Follow the Walking Skeleton
  13. 13. Be smart about the scope • Avoid "Death by user stories" / feature shopping list • Agree what the MVP / Walking Skeleton is and focus on it • Goal is to prove that the team is able to deliver • Show value to the business • Call out unrealistic requirements
  14. 14. Impact Mapping2 2 https://www.impactmapping.org/
  15. 15. Lesson 3: Do not ignore Legacy Design
  16. 16. Design • Make sure to have right people in the room • Include Domain Experts, Legacy Developers, Business • Make sure you understand well why rewrite is happening • Focus on "what" not "how" • Explore options / deliberate discovery 3 3 https://lizkeogh.com/2012/09/21/the-deliberate-discovery-workshop/
  17. 17. Design • "Ubiquitous language" of legacy • Language needs to evolve • It's impossible to design a system without considering technology • Ensure good facilitation
  18. 18. Lesson 4: Bounded Contexts are not Microservices
  19. 19. Microservices • Consistency as a driver • Aggregates define consistency boundaries • Consistency is defined by business, not developers! • Where are good, old modules/packages • Ports as deployable components
  20. 20. Lesson 5: Event Sourcing: beauty is only skin deep
  21. 21. Event Sourcing • Sometimes make a lot of sense • ES based model allowed us to simplify some complex processes • Projections make integration easy • Start with really specific and reach events • Separate aggregate state from apply and from handle • Testing is explicit
  22. 22. Event Sourcing • Lack of expertise / lesser known • Event based integration • Idempotency and delivery guarantees • Eventual consistency • Synchronous commands • Migration of CRUD models • Event stream housekeeping
  23. 23. Summary • Find explicit boundaries of rewrite with Context Mapping • Minimise number of changes at a time • Use Walking Skeleton / MVP approach • Learn from legacy designs but remember reasons for rebuild • Base the design on Aggregate consistency • Make sure you have good reason to use Event Sourcing
  24. 24. Thanks! @cakper / kacper@gunia.me
  25. 25. References • Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans • Getting started with DDD when surrounded by legacy systems - Eric Evans • Versioning in an Event Sourced System - Gregory Young • Impact Mapping: Making a Big Impact with Software Products and Projects - Gojko Adzic • Graphic - own resource, Public Domain photos from pixabay.com, Impact Mapping graphic from www.impactmapping.org

×