Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

All the cool kids....

3.053 Aufrufe

Veröffentlicht am

The PHP world is spinning quite fast these days. There’s a lot to keep up with. You can’t be an expert in all subjects, so you need a way to find out what’s relevant for you and your team. Which approaches to software development would be useful? Which programming paradigms could help you write better code? And which architectural styles will help your application to survive in this quickly changing world? In this talk I’ll help you answer these questions by taking a bird’s-eye view. I will quickly guide you along some of the most fascinating topics in modern PHP development: DDD, BDD, TDD, hexagonal architecture, CQRS, event sourcing and micro-services. We’ll see how these things are related to each other, and how understanding and applying them can help you improve your software projects in many ways.

Veröffentlicht in: Software

All the cool kids....

  1. 1. Yeah, they're invincible, and she's just in the background And she says: “I wish that I could be like the cool kids.”
  2. 2. All the cool kids… @matthiasnoback CTO at
  3. 3. What is cool? NoSQL?
  4. 4. ? ?
  5. 5. ?
  6. 6. http://nosql-database.org/ What’s this?
  7. 7. Conclusion: Use “cool” things when you understand them
  8. 8. What else is cool? JavaScript?
  9. 9. ? ? ? ? ?
  10. 10. Conclusion: Use “cool” things that last
  11. 11. Not what this talk is about
  12. 12. DDD BDD Microservices CQRS/ES Hexagonal architecture
  13. 13. These things are “cool” But they aren’t a hype They have a proven track record
  14. 14. Why do we need to talk about them again?
  15. 15. Serious psychological impediments “I want to do what they do” “I’m scared” “I’m doing quite well” “You can’t have it all”
  16. 16. To be honest
  17. 17. Our projects may be Too simple Too small Too short-lived Too much time-constrained
  18. 18. Overcoming anxiety You can do it! You’ll get used to it You could do much better There are “light” options
  19. 19. You just need to: Listen Read Practice
  20. 20. About DDD domain-driven design Eric Evans
  21. 21. Tactical patterns
  22. 22. Entities Locus of change Identifiable Can act as the root of a bigger aggregate
  23. 23. Value Objects Immutable Describe aspects of an entity
  24. 24. Aggregates Compositions of Entities and Value Objects Transactional boundary
  25. 25. Repositories Act as collections of aggregates
  26. 26. Domain Events Immutable Notification of change inside an entity
  27. 27. What changes? We don’t design with the database in mind (we design the objects) We don’t calculate change sets anymore (we only touch one aggregate)
  28. 28. So far, much of DDD is just “better programming”
  29. 29. Ubiquitous Language The language spoken by both software developers and business people Prevents translations between business and implementation domain language central to DDD
  30. 30. Core Domain The aspect of the business domain that is distinctive Good software should make a big difference here
  31. 31. Generic subdomain The software for this can be a standard solution or outsourced
  32. 32. Bounded Context There is a boundary for domain models The meaning and relevance of concepts ends at the boundary Allows for separate teams to work on a model
  33. 33. Strategic patterns
  34. 34. This is so very useful
  35. 35. Which bounded contexts exist? How do they map to (sub)domains of the business? What are the relationships between the teams responsible for them?
  36. 36. This is where we can vastly expand our horizons
  37. 37. Event storming
  38. 38. Interviewing domain experts
  39. 39. Crunch domain knowledge Grow a model Refine a model Make it do useful work “software that matters” agile
  40. 40. As a software developer you should be cool and be part of this movement
  41. 41. About BDD behavior-driven development Dan North
  42. 42. I want… Okay stakeholder programmer Agile!
  43. 43. What’s the next most important thing the system doesn’t do? heuristic
  44. 44. As a … I want to … So that … user story
  45. 45. Given … When … Then … Given … When … Then … Given … When … Then … scenarios, examples, acceptance criteria
  46. 46. Given … When … Then … Make executable
  47. 47. –Dan North “BDD is about implementing an application by describing its behavior from the perspective of its stakeholders”
  48. 48. Write a failing acceptance test Write a failing unit test Make the test pass
  49. 49. BDD is an agile methodology for creating software that matters
  50. 50. Ubiquitous language Expected behavior Requirements analysis Domain experts Acceptance criteria just like with DDD!
  51. 51. Testing and the tools are only of “secondary” interest but great nonetheless!
  52. 52. Modelling by Example Konstantin Kudryashov
  53. 53. Design your domain model guided by examples
  54. 54. Domain Application Infrastructure database UI HTTP filesystem
  55. 55. Test your scenario’s against the application or domain layer Domain Application
  56. 56. Run some scenario’s against the infrastructure layer Domain Application Infrastructure
  57. 57. Unit Acceptance UI Ciaran McNulty
  58. 58. BDD, modelling by example: cool and very helpful for reaching the goals set by DDD
  59. 59. About CQRS and Event Sourcing
  60. 60. First: what’s CQS command query separation Bertrand Meyer
  61. 61. class Entity
 private $information;
 public function changeInformation($information)
 $this->information = $information;
 public function getInformation()
 return $this->information;
 } command function query function
  62. 62. Second: what’s CQRS command query responsibility segregation Greg Young
  63. 63. class Entity
 private $information;
 public function changeInformation($information)
 $this->information = $information;
 class ReadModel
 private $information;
 public function getInformation()
 return $this->information;
 } command function query function
  64. 64. Entity ReadModel Database “CQRS lite”
  65. 65. Entity ReadModel Database Database ?
  66. 66. Domain events! just like with DDD (again)
  67. 67. Entity Domain event ReadModel External serviceReadModel projection tailor-made for a particular view
  68. 68. Entity created Information changed Some other event Yet another event Event store
  69. 69. Domain event Report AnalyticsNew read model add new subscribers at any time
  70. 70. Visualise event streams Jef Claes
  71. 71. Look into CQRS and ES because: Your “reads” will be more efficient Your reports/statistics/… are very valuable for you/your clients It fits very well with DDD It makes your application ready for the next challenge…
  72. 72. About Microservices Sam Newman
  73. 73. Something known as a monolith
  74. 74. Micro- service Micro- service Micro- service Micro- service Micro- service better!
  75. 75. Micro- service Micro- service Micro- service Micro- service Micro- service
  76. 76. Micro- service Command Event Command Event loose coupling (dependency inversion)
  77. 77. Micro- service Storage Decentralized data
  78. 78. Micro- service Service-oriented Command Query
  79. 79. Micro- service Event Event-driven
  80. 80. Micro- service Ideally mapped to Bounded Contexts Yes… DDD!
  81. 81. Micro- service Micro- service Replaceable
  82. 82. Micro- service Different technologies Micro- service Micro- service
  83. 83. Microservices done right: Resilient Redundant Separately deployable Decoupled Need a lot of: Monitoring Automation
  84. 84. Most importantly: it should fit within your organisation Cross-functional teams Different ways of cooperation (Context Map) A microservice architecture offers scaling options for your developer team
  85. 85. Ignore all the jokes on Twitter and look into this cool thing
  86. 86. The cool kids
  87. 87. Who are they? The people at company X? Teams who use Y in production? People who have a Google Friday? Companies with picknick tables and fake grass? People with a Raspberry Pi continuous deployment pipeline?
  88. 88. It turns out… you are the cool kids
  89. 89. You know more than you think You do special things You’re beautiful
  90. 90. Share what you do interesting!wow! aha!
  91. 91. Push yourself to the limit
  92. 92. Learn about the cool stuff that’s here to stay DDD BDD Microservices CQRS/ES Hexagonal
  93. 93. Abstract the fashionable details
  94. 94. Thank you! legacy.joind.in/16397
  95. 95. Recommended reading Domain Driven Design (Eric Evans) Implementing Domain Driven Design (Vaughn Vernon) Growing Object-Oriented Software Guided by Tests (Steve Freeman & Nat Pryce) Microservices (Sam Newman) Modelling by Example (Konstantin Kudryashov)