https://matthiasnoback.nl Web application frameworks are indispensable. You wouldn't want to deal with raw HTTP messages yourself, nor build your own router, or ORM. But if you're not careful, a framework will take over your entire project. Business logic and framework-specific code will end up being mixed together, in controllers, services and entities. Not being able to describe the use cases of your application without also talking about HTTP, or SQL, leads to hard-to-test and hard-to-change application code. Your core code will be tied to your framework, which endangers the future of the project in the long term. In this talk I'll explain how to make a clean separation between your own business logic and the code that makes your application's use cases available to the world outside. We'll discuss architectural concepts like "layers" and "ports & adapters", and how applying them will make your application flexible enough to deal with a constantly changing environment.

1. Advanced Web Application
Architecture
@matthiasnoback
info@matthiasnoback.nl
Slides are onTwitter

3. Change is really hard for most
software projects I've encountered

4. Change rate
Framework maintainers

5. Change rate
Business logic

6. Reasons for change
Framework integration code

7. Reasons for change
Remote service calls

8. Reasons for change
Domain model

9. Single responsibility principle
for architecture
What changes for the same reason
should be grouped together

10. Examples
● All the things related to your framework
● All the things related to your domain model
● All the things related to your database
● ...

11. The most important distinction is...
Not too many groups

12. Domain vs Infrastructure
● Model
(entities, value objects)
● Use cases
(application services)
● Interfaces for boundary
objects
● Framework-specific code
● Implementations for
boundary objects
● Web controllers, CLI
controllers, etc.

13. Step 1
Introduce layers

14. Step 1: Introduce layers
Web framework
Domain logic
Database integration

15. Introduce layers
Web framework
Domain logic
Database integration
InfrastructureDomain

16. Step 2
Define ports and adapters
(Hexagonal architecture; Alistair Cockburn)

17. Determine actors
Application
Primary actor:
User
Secondary actor:
Database
Primary actor:
User
Secondary actor:
Remote
webservice
Primary actor:
Cronjob

18. Make a distinction...
Between the intention for communication,
and the supporting implementation

19. Examples
The user can buy a ticket

20. Examples
We have a TicketsController with a
buyTicket action. It gets the logged in user from
the session and gets the user's address from the
submitted form data.

21. Examples
We need to persist an order

22. Examples
We store order data in an orders table in our
MySQL database. We use Doctrine DBAL to talk
with that database.

23. Ports
Buyaticket
Persistanorder

24. Adapters
Buyaticket
Persistanorder
HTTPadapter
SQLadapter

25. Advantages
By separating domain from infrastructure code you
automatically increase testablity

26. Advantages
You can replace an adapter without
affecting the ports

27. Advantages
You can postpone the choice for
database vendor, framework, ORM, etc.

28. Advantages
You can more easily keep up with
the change rate of framework-specific code

29. Advantages
Or replace the framework altogether...

30. Sources
● Alistair in the "Hexagone": https://www.youtube.com/watch?v=th4AgBcrEHA
● My upcoming book "Advanced Web Application Architecture"
https://leanpub.com/web-application-architecture/
● Nat Pryce, Steve Freeman - Growing Object-Oriented Software, Guided by Tests
● Vaughn Vernon - Implementing Domain-Driven Design (see the chapter about
Architecture)

31. Q & A

32. Thank you!
@matthiasnoback
info@matthiasnoback.nl