This workshop covers all of the three layers from what is known as a layered architecture: the domain, application and infrastructure layer. Protecting your high quality domain model can be accomplished by applying a so-called ports & adapters or hexagonal architecture. And you'll find out how your application's design really starts to flourish when you use CQRS with Event Sourcing. Some of the keywords for this workshop: aggregate design, domain events, application services, commands, queries and events, event sourcing, projections, eventual consistency, layered architecture, ports & adapters, hexagonal architecture. What you'll learn from this tutorial: * Design a clean domain model * Model your application's use cases as application services * Connect those well-designed layers to the world outside

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.

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

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

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

13. Part 1: Layers

14. 14 / 76
Traditional layering
view
controller
model

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

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

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

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

19. 19 / 76
Use cases
● Vertical division

20. 20 / 76
Layers: combine both

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

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

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

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

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

26. 26 / 76
Part 2: Ports & Adapters

27. 27 / 76
Messaging is the big idea

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

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

30. 30 / 76
Hexagonal architecture
User interface
Persistence

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

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

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

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

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

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

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

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

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

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

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

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

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

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

45. 45 / 76
Application services
● Transactional consistency

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

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

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

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

50. 50 / 76
Dependency inversion principle
use

51. 51 / 76
Dependency inversion principle
use implement

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

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

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

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

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

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

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

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

60. 60 / 76
Part 3: Testing

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

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

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

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

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

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

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

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

69. 69 / 76
Persistence
FileBased InMemory
Port
Adapters

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

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

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

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

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

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

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