This talk was delivered at the PHPers meetup in Wroclaw, 10 August 2015. I presented a set of techniques which help you transition from a legacy codebase to DDD. I focused more on the strategic DDD patterns like bounded contexts. The main idea in such refactorings is to: 1. List all your (potential) bounded contexts 2. Decide which ones are deserving the DDD tactical patterns 3. Decide which ones can stay as CRUD 4. Communicate between the BCs via events

1. From legacy to DDD
@andrzejkrzywda
Arkency

2. Did you write any
code today?

3. Was it good code?

4. Are you proud of it?

5. Why?
(do you think that surgeons are proud of their work?)

6. What is legacy code?
Ruby is much more unified here than PHP
Any Rails code is legacy code

7. Legacy
• Frameworks
• monolithic
• no architecture
• no tests

8. DDD

9. Strategic vs Tactical
DDD

10. Tactical DDD
• entity
• value objects
• aggregate
• domain event
• services
• repositories
• factory

11. DDD-lite
• app service
• domain service
• load aggregate from the repo
• do sth cool
• may use some value objects
• may trigger some domain events
• save aggregate (repo)

12. Strategic DDD
• bounded contexts
• context map

13. http://martinfowler.com/bliki/BoundedContext.html

14. Software House
management tool

15. as microservices
partially available
different persistence
data duplication
Context Map
HR Project Management Finances
Invoicing
CRUD
DDD-lite
external SaaS
Communication
developer
project
client

16. How to get there from
legacy?
BTW, There’s no such thing as the ultimate DDD codebase

17. Draw the Context Map
the only thing to remember from this talk

18. Ongoing process
No time for 2-months rewrites

19. Peopleware
the human factor
http://andrzejonsoftware.blogspot.com/2014/01/refactoring-human-factor.html

20. Escape from the
CRUD verbs
Talk more to the business people

21. Test coverage
#noregressions
when you’re a client you don’t like them too

22. Mutation testing
is the real test coverage!
http://blog.arkency.com/2015/04/why-i-want-to-introduce-mutation-testing-to-the-rails-event-store-gem/
http://blog.arkency.com/2015/06/how-good-are-your-ruby-tests-testing-your-tests-with-mutant/

23. mutation testing
php - humbug
https://github.com/padraic/humbug

24. Test units, not classes!
http://andrzejonsoftware.blogspot.com/2015/02/tdding-unit-not-class.html
http://andrzejonsoftware.blogspot.com/2014/04/tdd-and-rails-what-makes-good-unit.html
http://blog.arkency.com/2014/09/unit-tests-vs-class-tests/

25. Escape from the
framework ASAP
http://blog.arkency.com/2015/03/extract-a-service-object-in-any-framework/
Call application services from the framework

26. Active Record doesn’t
make your code happy
AR is not DDD-lite-friendly
Data Mapper is better here

27. Don’t just pass the
params/hash everywhere
http://andrzejonsoftware.blogspot.com/2011/12/args-opts-params.html

28. Wrap your legacy
contexts with the
application services layer

29. Use events to
communicate between
bounded contexts
rails_event_store

30. Separate reads/writes
at the services layer
CQRS

31. Eliminate querying
from BC to another
Push the data!

32. Keep the Bounded Contexts
in-sync by publishing all the
important events

33. Easier testing when no
dependency on other
system

34. Read models
Denormalized data

35. Treat your frontend as a
separate Bounded
Context

36. When in doubt, think
in aggregates

37. Event sourcing
build your aggregates from events
audit log for free
(no, it’s not slow, but thanks for asking)

38. Distributed
transactions are tricky

39. Easier setup of the
project when it’s a smaller
piece
Useful when you’re maintaining many projects and need to bugfix them from time to time

40. https://laracasts.com/discuss/channels/general-discussion/folder-and-namespace-structure-with-ddd/replies/17753

41. Legacy -> DDD books
• red book, Vaughn Vernon
• blue book, Eric Evans
• Refactoring, Fowler
• Legacy code, Feathers

42. THANKS!
(go draw your context maps now)