DDD Beyond Layers

Transcript

1. DDD beyond Layers
2. Introduction Aka who the heck is this guy? 1
3. I am Lucas Uyezu I am here because I love talking about software. You can find me at @coralton Hello!
4. *We're hiring
5. Target audience Aka is this talk for me? 2
6. Target Audience ◉ Beginner and Intermediate level developers ◉ People working on a production app that are considering refactoring or even rewriting it
7. Target Audience ◉ This talk is not a DDD workshop ◉ This talk is about sharing knowledge gained through experience ◉ There is excellent material about DDD online
8. What is DDD? 3
9. “ Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.
10. … an evolving model of the core business concepts. ◉ An evolving model is not "done"
11. Why DDD? 4
12. Why DDD? ◉ We want to move faster ◉ We want to go home (Who likes crunching?) ◉ We don't want to fail: ◦ Fail by having the project rewritten ◦ Fail by not delivering value soon enough and have the company go under ◦ Fail by not delivering value soon enough and being fired
14. History of DDD in Ruby 5
15. ◉ Rails is a MVC framework ◉ Rails is Domain aware, it gives you a domain layer, aka as the Model ◉ You're supposed to put your business logic in the model ◉ However, over time the model becomes too small for an evolving set of business logic ◉ Active Record -> Active Model DDD in Ruby's history
16. ◉ There is a new generation of frameworks that acknowledges more concepts of the Domain Model. ◉ Instead of just Models you have Repositories, Entities. DDD in Ruby's history
17. ◉ Programmers using both generations of frameworks suffer from the same problem: ◉ If you use your framework's features to define your domain model, eventually your infrastructure will not accommodate you evolving business logic. DDD in Ruby's history
18. DDD Crash Course 5 Aka talk is cheap, show me the code
19. “ Drivers get their licenses suspended when they accumulate 20 demerit points over the course of a year
21. ◉ Things the domain does care about: ◦ How many points will suspend a driver? ◦ How long do points count towards suspension? ◉ Things the domain doesn't care about: ◦ New URL for fetching infractions ◦ Infractions are now coming from a FTP text file ◦ New HTTP client, faster, more secure ◦ What if the web service doesn't have a test endpoint? DDD Crash Course
26. What does DDD mean beyond layers, frameworks and tools? 6
27. DDD means better testing 6.1
32. ◉ Testing on a local/test database with 100 records. If you forget an index on the DB you'll have to rollback ◉ You'll need a test/staging env as close as possible to production ◉ DDD vs 12 factor app* Beware of pitfalls though *https://12factor.net
33. DDD means ubiquitous language 6.2
34. ◉ If you go through iterations of brainstorming sessions with domain experts, you'll find hidden entities within your models ◉ Domain experts know stuff you don't DDD means ubiquitous language
35. “ If sophisticated domain experts don’t understand the model, there is something wrong with the model.
36. “ Developer: Who decides when demerit points expire? Will this change often? Domain Expert: That's how long infractions stay active on a driver's record.
41. DDD means refactorings 6.3
43. ◉ DDD stands for Domain Driven Design ◉ Some people think of DDD as a tool, but Design skills need to be developed over time ◉ You will discover improvements/mistakes along the way ◉ An environment that fosters refactorings will make your life better DDD means refactorings
46. Summarizing 7
50. ◉ Only splitting business logic into repositories and services is not enough. ◉ Domain/Application/Infrastructure ◉ DDD can fail if an evolving model does not come with a decent shipping pipeline. ◉ Deploying once a month is not enough. ◉ What's the cost of replacing obsolete libraries? E.g. Resque vs Sidekiq, HTTParty vs Faraday Conclusion
51. Any questions ? You can find me at ◉ @coralton ◉ lucas@uyezu.com Thanks!
52. Homework 8