Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

From legacy to DDD (slides for the screencast)

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 45 Publicité

Plus De Contenu Connexe

Diaporamas pour vous (16)

Les utilisateurs ont également aimé (20)

Publicité

Similaire à From legacy to DDD (slides for the screencast) (20)

Plus par Andrzej Krzywda (17)

Publicité

Plus récents (20)

From legacy to DDD (slides for the screencast)

  1. 1. From legacy to DDD @andrzejkrzywda Arkency
  2. 2. What is legacy code?
  3. 3. Legacy • Frameworks • monolithic • no architecture • no tests
  4. 4. DDD
  5. 5. Strategic vs Tactical DDD
  6. 6. Tactical DDD • entity • value objects • aggregate • domain event • services • repositories • factory
  7. 7. DDD-lite • app service • calls 1 or more domain services • domain service • takes repo as input • load aggregate from the repo • do sth cool • may use some value objects • may trigger some domain events • save aggregate (repo)
  8. 8. • URL • Rails action • App service • Domain service • Repo • ActiveRecord • Database
  9. 9. One app service can call multiple domain services
  10. 10. UpdateCustomer == MoveToNewAddress ChangeEmail IntroduceNewContactPerson In one of our projects one request was about 15 domain services “Update” is always hiding a lot
  11. 11. Strategic DDD • bounded contexts • context map
  12. 12. http://martinfowler.com/bliki/BoundedContext.html
  13. 13. Software House management tool
  14. 14. optionally as microservices partially available different persistence data duplication Context Map HR Project Management Finances Invoicing CRUD DDD-lite external SaaS Communication developer project client DDD-lite
  15. 15. How to get there from legacy? BTW, There’s no such thing as the ultimate DDD codebase
  16. 16. Draw the Context Map aka what are the boxes in your application aka you have more apps They are potential microservices
  17. 17. Decide which contexts are CRUD and which ones need more logic (DDD-lite) the ones with CRUD ideally need to publish events anyway
  18. 18. Ongoing process No time for 2-months rewrites
  19. 19. Peopleware the human factor http://andrzejonsoftware.blogspot.com/2014/01/refactoring-human-factor.html
  20. 20. Escape from the CRUD verbs Talk more to the business people
  21. 21. Test coverage #noregressions when you’re a client you don’t like them too
  22. 22. Line coverage is a joke
  23. 23. 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/
  24. 24. You want to try mutant (today) https://github.com/mbj/mutant
  25. 25. mutant == testing your tests == refactoring with confidence
  26. 26. 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/
  27. 27. Escape from the framework ASAP http://blog.arkency.com/2015/03/extract-a-service-object-in-any-framework/ Call application services from the framework
  28. 28. Active Record doesn’t make your code happy AR is not DDD-lite-friendly Data Mapper is better here
  29. 29. ActiveRecord is a short-term loan are you able to pay the debt? what is your credit history?
  30. 30. Don’t just pass the params/hash everywhere http://andrzejonsoftware.blogspot.com/2011/12/args-opts-params.html
  31. 31. Wrap your legacy contexts with the application services layer
  32. 32. Use events to communicate between bounded contexts https://github.com/arkency/rails_event_store https://github.com/arkency/ruby_event_store
  33. 33. Sync may be safer than async
  34. 34. Separate reads/writes at the services layer CQRS
  35. 35. Eliminate querying from BC to another Push the data!
  36. 36. Keep the Bounded Contexts in-sync by publishing all the important events
  37. 37. Easier testing when no dependency on other system
  38. 38. Read models Denormalized data
  39. 39. Treat your frontend as a separate Bounded Context
  40. 40. When in doubt, think in aggregates
  41. 41. Event sourcing build your aggregates from events audit log for free (no, it’s not slow, but thanks for asking)
  42. 42. Distributed transactions are tricky
  43. 43. 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
  44. 44. Legacy -> DDD books • red book, Vaughn Vernon • Implementing DDD • blue book, Eric Evans • Refactoring, Fowler • Legacy code, Feathers • Fearless Refactoring: Rails Controllers
  45. 45. THANKS! andrzej@arkency.com

×