Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Decoupling from infrastructure - Training

Most application code freely mixes domain logic with infrastructural concerns. Models are directly tied to the relational database of the project, use cases are inseparable from their web controllers, and external services are used without an appropriate abstraction. This limits your ability to design the application in a domain-driven, test-first way.

What we need is a way to separate core code from infrastructure code. And that’s surprisingly easy. All the design patterns have already been invented for that. Until we run out of time, we’ll keep (re)discovering patterns like Controller, Application Service, Entity, Read Model, Domain event, and so on. These patterns can be used to establish a testable, portable application core, with a focus on behavior, instead of data.

  • Login to see the comments

Decoupling from infrastructure - Training

  1. 1. Decoupling from infrastructure Matthias Noback @matthiasnoback
  2. 2. Not coupling to infrastructure in the first place Matthias Noback @matthiasnoback
  3. 3. Why do you want this? ● You can start coding and get feedback about your work from day one ● Non-infrastructure code is testable by definition
  4. 4. Using ● DDD (patterns, collaboration) ● TDD (Gherkin scenarios, unit tests) ● #NoFramework ● #NoDatabase
  5. 5. Why do you want this? ● You can deliver value quickly and often ● You can use DDD patterns and ports & adapters not just for the sake of it, but because it makes your Agile better
  6. 6. Core code or infrastructure code? Rule 1: Core code doesn't directly depend on external systems, nor does it depend on code written for interacting with a specific type of external system.
  7. 7. Core code or infrastructure code? Rule 2: Core code doesn't need a specific environment to run in, nor is it designed to run in a specific context only.
  8. 8. Process modeling: focuses on the real thing Users making decisions, gaining value from your system
  9. 9. What do we need? Design patterns: Application services Entities and Entity repositories Domain events and Event subscribers Read models and Read model repositories
  10. 10. Demo of the technology PHPStan PHPUnit Behat (in that order) (bin/
  11. 11. When the organizer schedules a new training called "Decoupling from infrastructure" for "24-01-2020" Command & Application service Entity?Entity?
  12. 12. Then it shows up on the list of upcoming events Read model?
  13. 13. When ... Then... Domain event? Event subscriber?
  14. 14. Application service ● A service with a single command method ● Dependencies injected as constructor arguments ● Primitive-type arguments
  15. 15. The recipe ● Create the entity ● Save it using the injected repository or ● Retrieve an entity ● Update it ● Save it
  16. 16. Entity repository ● An interface (e.g. TrainingRepository) ● An implementation (e.g. InMemoryTrainingRepository )
  17. 17. Entity ● An object that keeps the application's state ● It guards against invalid application state ● It's action-based ● It records domain events
  18. 18. Domain event ● An object representing the change in an entity ● Also useful if you don't do event sourcing.
  19. 19. Event subscriber ● Subscribes to events and takes further action (makes its own decisions) (see EventDispather in TestServiceContainer). ● Sometimes called "Policy"
  20. 20. Guide Run the scenario (maybe remove the @ignore part from the one you want to work on) Which step is still pending?
  21. 21. Guide Collect design patterns that will be handy In the code, use words from the scenario Implement the step (make it green)
  22. 22. Iterate And increment
  23. 23. Practical suggestions git checkout -b your_own_branch_name That way you can do: git checkout master git pull (in case I update master)
  24. 24. 1 printed copy 2 digital copies
  25. 25. When you feel liking talking to an external system (remote API, database, file system)... Talk to an interface instead
  26. 26. Our chief weapon is Abstraction
  27. 27. Service needs a database Database Service needs to save something Saves something in the database Something-saver (repository) Class Interface Class
  28. 28. Feedback? @matthiasnoback
  29. 29.