Refactoring legacy systems using events commands and bubble contexts

A summary of my 5-year journey through refactoring a legacy system using events, commands, and bubble context.

1. www.accesto.com
Refactoring legacy

Using events, commands and
bubble context




Michał Kurzeja, PHPers Summit 2024

3. Dealing with legacy

4. Dealing with legacy

5. Refactor
Do nothing Strangle
Start from scratch

6. Strangler pattern?

9. Great approach, but
not always possible

10. You are on Symfony 5.4?

We need to write a new
version on 6.4!

11. You are on Symfony 5.4?

We need to write a new
version on 6.4!

12. Refactor
Do nothing Strangle
Start from scratch

15. Selecting the right driver is essential

16. 1.
2.
3.
0.
4.

17. Event/Command
approach to a rewrite

18. You mean CQRS
right?

19. Don’t care much, as
long as I have events.

20. Step 1. Extracting events

23. ?

24. Requesting, not just
reacting

25. Extracting commands

27. Reading data

28. OK, but does that really
make our code better?

29. Reasons for a
refactor/rewrite

30. Bad code
1. Low level issues
2. Higher level issues
3. Not the newest FW
4. FW dead for ages

31. Business issues
1. Bad abstractions
2. Business is a mess too

32. Bad code vs
Business issues

35. Business focused
techniques

36. DDD* ?

39. 1. Bubble context

48. What about writing
data?

49. Writing to DB directly?

52. Writing via API

53. Bubble context summary
1.Modest commitment to DDD
2.No synchronisation risk
3.Works when there is a limited range of data needed from legacy
4.Fully dependent on legacy

54. 2. Autonomous Bubble

57. How to implement
the sync?

58. SLA vs maintenance
cost

59. 2.1 Batch Job

61. 2.2 Domain events

63. What about writing
data?

64. What about writing
syncing data?

65. Avoid writing from
two parts

67. Boundary can be quite low:
Task Entity:

●Id
●Title
●Description
●Status
●Member

68. Autonomous Bubble summary
1.Higher commitment required.
2.Data used without legacy being involved.
3.Allows to decouple new part to evolve.
4.Can be introduce as a next step for bubble context.

69. 3. Open host

71. New, generic model

72. New, generic model

73. New, generic model
Another model, created for this context

74. New, generic model
Another model, created for this context

75. Let’s get back to the
two questions we
left unanswered

76. Why implement New
-> Legacy flows
using commands?

78. ACL in a command<->handler flow
●Lazy approach
●Move legacy code to handler (in legacy namespace)
●Legacy is forced to use new model
●Clean approach
●Expose a clear API (interface, facade, etc) from legacy
●Implement a client in the new part
●Handler can also be in the new part

86. Questions?

89. Pytania po prezentacji? Napisz do mnie! :)
[email protected]
accesto.com/blog/
Kontakt
twitter.com/accestoPL
facebook.com/accesto