1.
1 / 76
Advanced Application Architecture
Layers, Ports & Adapters
Matthias Noback
info@matthiasnoback.nl

2.
2 / 76
Slides are on Twitter
● @matthiasnoback
● https://twitter.com/matthiasnoback

3.
3 / 76
https://github.com/matthiasnoback/layers-ports-and-adapters-workshop/

4.
4 / 76
Demo time
http://localhost:8080

5.
5 / 76
Architecture
● Application-level design
● An application’s relation with other systems
● Framework/library/vendor choices?
● Big design upfront?

6.
Frameworks dictate the structure of your project

7.
High-level structural elements
● Models/entities
● Controllers
● Views/templates
● Migrations
● Configuration

8.
Thin controllers, fat models
● "Only briefly visit your controller, go to your model
as fast as you can."
● In practice: we build services, lots of them, and large
ones too.

9.
The effects of a framework-driven
architecture
● Implicit use case scenarios
● Implicit connections to actors
● Coupling to the framework

10.
Why bad?
● Scenarios are interrelated (legacy spaghetti)
● Domain logic is mixed with infrastructure logic
● Impossible to switch frameworks

11.
What do we want?
● The ability to focus on domain logic without thinking
about storage, web service, web requests, etc.
● The ability to switch to a different database,
framework, message queue, filesystem, etc.

12.
Part 1: Layers

13.
14 / 76
Traditional layering
view
controller
model

14.
15 / 76
Layers
● Help you protect what's in a deeper layer

15.
16 / 76
Layers
● Allow you to define dependency rules

16.
17 / 76
Layers
● Define the right place to put things

17.
18 / 76
Layers
● Horizontal division (as opposed to...)

18.
19 / 76
Use cases
● Vertical division

19.
20 / 76
Layers: combine both

20.
21 / 76
Cohesion – A basic set of layers
● Infrastructure
● Application
● Domain

21.
22 / 76
Layer conventions
Domain model:
➤ Entities
➤ Value objects
➤ Domain services
➤ Factories
Business logic
Decisions
Data
State
Behavior
● Domain layer

22.
23 / 76
Layer conventions
➤ Find an object
➤ Change something
➤ Notify something
➤ Get some information
Use cases
Orchestration
● Application layer

23.
24 / 76
Layer conventions
Communication with:
➤ HTTP client
➤ Database
➤ Filesystem
➤ Email server
➤ Message broker
Connecting the
application to the
world outside
● Infrastructure layer

24.
25 / 76
assignment/01.md
● Layers

25.
26 / 76
Part 2: Ports & Adapters

26.
27 / 76
Messaging is the big idea

27.
28 / 76
Ports (cohesion)
User interface
Persistence
● Web, CLI, test client, messages, database queries

28.
29 / 76
Ports... And adapters
HTTP
SQL
● Translation

29.
30 / 76
Hexagonal architecture
User interface
Persistence

30.
31 / 76
Ports... And adapters
(De)serialization, translation, structural
validation
HTTP
SQL

31.
32 / 76
assignment/02.md
● Ports

32.
33 / 76
Port Adapters
● ...in the Infrastructure layer

33.
34 / 76
Application services
● ... in the Application layer

34.
35 / 76
Domain model
● … in the Domain layer

35.
36 / 76
Application services
● Delivery-mechanism agnostic

36.
37 / 76
Application services
● Also known as "command handlers"
● Command object is a DTO
● Represents a user's intention
● Contains primitive-type values

37.
38 / 76
Application services
● Translate, and orchestrate
● From primitive-type values to rich domain objects
● Manipulates an entity
● Persists it
● May dispatch events

38.
39 / 76
assignment/03.md
● Input adapters

39.
40 / 76
Validation
● At multiple levels:
● Structural validation of messages
● User-friendly input validation
● Domain invariant protection

40.
41 / 76
Structural validation
● In the infrastructure layer:
● Form keys
● JSON schema

41.
42 / 76
User-friendly input validation
● Also in the infrastructure layer
● Usability concern
● Prevent problems later on
● Localized, translated
● Friendly

42.
43 / 76
Domain invariant protection
● In Application and Domain layer
● Domain objects: always valid
● Valid state
● Valid state transitions

43.
44 / 76
assignment/04.md
● Input validation

44.
45 / 76
Application services
● Transactional consistency

45.
46 / 76
Coupling – The Dependency rule
● Layers should only depend on deeper layers

46.
47 / 76
Coupling – The Dependency rule
● Infrastructure
● Application
● Domain

47.
48 / 76
Dependency inversion principle
● Classes should always depend on things that are
more abstract

48.
49 / 76
Dependency inversion principle
low-levelconcrete class specific
abstract interface generic high-level

49.
50 / 76
Dependency inversion principle
use

50.
51 / 76
Dependency inversion principle
use implement

51.
52 / 76
Coupling is about dependencies in
code
● Use Dependency Injection

52.
53 / 76
assignment/05.md
● Output adapter

53.
54 / 76
Incomplete entity
● A Meetup without an ID…

54.
55 / 76
Database-generated ID
● Faux-auto increment (check out the code)

55.
56 / 76
Alternative: UUID
● Universally Unique Identifier
● “7d7fd0b2-0cb5-42ac-b697-3f7bfce24df9”

56.
57 / 76
assignment/06.md
● A hidden dependency on the persistence mechanism

57.
58 / 76
Alternative: Sequence
● MeetupId encapsulates the type of ID used

58.
59 / 76
Advantages of using Layers,
ports & adapters
● Offers insight into the application
● Provides a useful convention for the team
● Isolates the low-level details
● Allows for alternative implementations
● Helps with testing

59.
60 / 76
Part 3: Testing

60.
61 / 76
Unit tests
● Testing your units of code
● One class at a time
● No IO
● No setup required
● Mocking only dependencies "you own"

61.
62 / 76
Integration tests
● Testing your adapters
● Maybe multiple classes
● Including IO
● Some setup required
● Mocking no dependencies

62.
63 / 76
Acceptance tests
● Testing your application services
● Multiple classes
● Use cases
● Infrastructure stand-ins

63.
64 / 76
System tests
● Testing your application end-to-end
● The real deal

64.
65 / 76
Testing pyramid
● Make it well-balanced
Unit
Integration
System
Acceptance

65.
66 / 76
Testing pyramid
● Make it well-balanced
Supports development
Prevents regressionSlow, brittle
Fast, stable
Proof of effectiveness
Proof of Correctness

66.
67 / 76
assignment/07.md
● Different types of tests

67.
68 / 76
Acceptance tests
● Use infrastructure stand-ins
Acceptance test
test the
application
layer

68.
69 / 76
Persistence
FileBased InMemory
Port
Adapters

69.
70 / 76
MeetupRepository
FileBasedMeetupReposit
ory
InMemoryMeetupReposit
ory
Domain
Infrastructure
implements implements

70.
71 / 76
assignment/08.md
● A test double for the Persistence port

71.
72 / 76
assignment/09.md
● An acceptance test for the application layer

72.
73 / 76
assignment/10.md
● Notifications

73.
74 / 76
A well-balanced test suite
● Adapters can be easily replaced
● Test suite is fast
● Feedback is quick
● Small amount of fragile tests
● Enables continuous delivery

74.
75 / 76https://matthiasnoback.nl

75.
76 / 76
Questions? Feedback?
info@matthiasnoback.nl
@matthiasnoback
https://joind.in/talk/89f5b