Talk delivered at Domain-Driven Design Exchange 2018 More Domain-Driven Design related content at: https://domaincentric.net/

1. Rebuilding Legacy Apps
with Domain-Driven Design1
1
Lessons learned

2. Kacper Gunia
• Independent consultant at Domain Centric
• Helping companies to be successful with DDD
• @cakper / kacper@gunia.me

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. Not all of a large system will be well designed
— Eric Evans

5. Legacy strategies by Eric Evans
1. Bubble Context
2. Autonomous Bubble
3. Exposing Legacy assets as services
4. Event Streams

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. 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. Lessons Learned

9. Lesson 1:
Context Map
is your friend

11. 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

13. 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

14. Lesson 2:
Follow the
Walking Skeleton

15. 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

16. Impact Mapping2
2
https://www.impactmapping.org/

17. Lesson 3:
Do not ignore
Legacy Design

18. 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/

19. Design
• "Ubiquitous language" of legacy
• Language needs to evolve
• It's impossible to design a system without considering
technology
• Ensure good facilitation

20. Lesson 4:
Bounded Contexts
are not Microservices

21. 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

22. Lesson 5:
Event Sourcing:
beauty is only skin deep

23. 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

24. 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

25. 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

26. Thanks!
@cakper / kacper@gunia.me

27. 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