1. Decoupling from
infrastructure
Matthias Noback
@matthiasnoback
info@matthiasnoback.nl

2. Not coupling to
infrastructure in the first
place
Matthias Noback
@matthiasnoback
info@matthiasnoback.nl

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. Using
●
DDD (patterns, collaboration)
●
TDD (Gherkin scenarios, unit tests)
●
#NoFramework
●
#NoDatabase

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. 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. 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.

9. Process modeling: focuses on the real thing
Users making decisions,
gaining value from your system

11. What do we need?
Design patterns:
Application services
Entities and Entity repositories
Domain events and Event subscribers
Read models and Read model repositories

12. Demo of the technology
PHPStan
PHPUnit
Behat
(in that order)
(bin/run_tests.sh)

13. When the organizer schedules a new training called
"Decoupling from infrastructure" for "24-01-2020"
Command &
Application service
Entity?Entity?

14. Then it shows up on the list of upcoming events
Read model?

15. When ...
Then...
Domain event?
Event subscriber?

16. Application service
●
A service with a single command
method
●
Dependencies injected as
constructor arguments
●
Primitive-type arguments

17. The recipe
●
Create the entity
●
Save it using the injected repository
or
●
Retrieve an entity
●
Update it
●
Save it

18. Entity repository
●
An interface (e.g.
TrainingRepository)
●
An implementation (e.g.
InMemoryTrainingRepository
)

19. Entity
●
An object that keeps the
application's state
●
It guards against invalid application
state
●
It's action-based
●
It records domain events

20. Domain event
●
An object representing the change
in an entity
●
Also useful if you don't do event
sourcing.

21. Event subscriber
●
Subscribes to events and takes
further action (makes its own
decisions) (see EventDispather
in TestServiceContainer).
●
Sometimes called "Policy"

22. Guide
Run the scenario (maybe remove the @ignore
part from the one you want to work on)
Which step is still pending?

23. Guide
Collect design patterns that will be handy
In the code, use words from the scenario
Implement the step (make it green)

24. Iterate
And increment

25. Practical suggestions
git checkout -b your_own_branch_name
That way you can do:
git checkout master
git pull
(in case I update master)

26. 1 printed copy
2 digital copies

27. When you feel liking talking to an external system
(remote API, database, file system)...
Talk to an interface instead

28. Our chief weapon is Abstraction

29. Service needs a database Database
Service needs to
save something
Saves something
in the database
Something-saver
(repository)
Class Interface Class

30. Feedback?
https://joind.in/talk/b1ae8
@matthiasnoback
info@matthiasnoback.nl

31. https://matthiasnoback.nl/training/