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.
1 / 76 Advanced Application Architecture Layers, Ports & Adapters Matthias Noback info@matthiasnoback.nl
2 / 76 Slides are on Twitter ● @matthiasnoback ● https://twitter.com/matthiasnoback
3 / 76 https://github.com/matthiasnoback/layers-ports-and-adapters-workshop/
4 / 76 Demo time http://localhost:8080
5 / 76 Architecture ● Application-level design ● An application’s relation with other systems ● Framework/library/vendor c...
Frameworks dictate the structure of your project
High-level structural elements ● Models/entities ● Controllers ● Views/templates ● Migrations ● Configuration
Thin controllers, fat models ● "Only briefly visit your controller, go to your model as fast as you can." ● In practice: w...
The effects of a framework-driven architecture ● Implicit use case scenarios ● Implicit connections to actors ● Coupling t...
Why bad? ● Scenarios are interrelated (legacy spaghetti) ● Domain logic is mixed with infrastructure logic ● Impossible to...
What do we want? ● The ability to focus on domain logic without thinking about storage, web service, web requests, etc. ● ...
Part 1: Layers
14 / 76 Traditional layering view controller model
15 / 76 Layers ● Help you protect what's in a deeper layer
16 / 76 Layers ● Allow you to define dependency rules
17 / 76 Layers ● Define the right place to put things
18 / 76 Layers ● Horizontal division (as opposed to...)
19 / 76 Use cases ● Vertical division
20 / 76 Layers: combine both
21 / 76 Cohesion – A basic set of layers ● Infrastructure ● Application ● Domain
22 / 76 Layer conventions Domain model: ➤ Entities ➤ Value objects ➤ Domain services ➤ Factories Business logic Decisions ...
23 / 76 Layer conventions ➤ Find an object ➤ Change something ➤ Notify something ➤ Get some information Use cases Orchestr...
24 / 76 Layer conventions Communication with: ➤ HTTP client ➤ Database ➤ Filesystem ➤ Email server ➤ Message broker Connec...
25 / 76 assignment/01.md ● Layers
26 / 76 Part 2: Ports & Adapters
27 / 76 Messaging is the big idea
28 / 76 Ports (cohesion) User interface Persistence ● Web, CLI, test client, messages, database queries
29 / 76 Ports... And adapters HTTP SQL ● Translation
30 / 76 Hexagonal architecture User interface Persistence
31 / 76 Ports... And adapters (De)serialization, translation, structural validation HTTP SQL
32 / 76 assignment/02.md ● Ports
33 / 76 Port Adapters ● ...in the Infrastructure layer
34 / 76 Application services ● ... in the Application layer
35 / 76 Domain model ● … in the Domain layer
36 / 76 Application services ● Delivery-mechanism agnostic
37 / 76 Application services ● Also known as "command handlers" ● Command object is a DTO ● Represents a user's intention ...
38 / 76 Application services ● Translate, and orchestrate ● From primitive-type values to rich domain objects ● Manipulate...
39 / 76 assignment/03.md ● Input adapters
40 / 76 Validation ● At multiple levels: ● Structural validation of messages ● User-friendly input validation ● Domain inv...
41 / 76 Structural validation ● In the infrastructure layer: ● Form keys ● JSON schema
42 / 76 User-friendly input validation ● Also in the infrastructure layer ● Usability concern ● Prevent problems later on ...
43 / 76 Domain invariant protection ● In Application and Domain layer ● Domain objects: always valid ● Valid state ● Valid...
44 / 76 assignment/04.md ● Input validation
45 / 76 Application services ● Transactional consistency
46 / 76 Coupling – The Dependency rule ● Layers should only depend on deeper layers
47 / 76 Coupling – The Dependency rule ● Infrastructure ● Application ● Domain
48 / 76 Dependency inversion principle ● Classes should always depend on things that are more abstract
49 / 76 Dependency inversion principle low-levelconcrete class specific abstract interface generic high-level
50 / 76 Dependency inversion principle use
51 / 76 Dependency inversion principle use implement
52 / 76 Coupling is about dependencies in code ● Use Dependency Injection
53 / 76 assignment/05.md ● Output adapter
54 / 76 Incomplete entity ● A Meetup without an ID…
55 / 76 Database-generated ID ● Faux-auto increment (check out the code)
56 / 76 Alternative: UUID ● Universally Unique Identifier ● “7d7fd0b2-0cb5-42ac-b697-3f7bfce24df9”
57 / 76 assignment/06.md ● A hidden dependency on the persistence mechanism
58 / 76 Alternative: Sequence ● MeetupId encapsulates the type of ID used
59 / 76 Advantages of using Layers, ports & adapters ● Offers insight into the application ● Provides a useful convention ...
60 / 76 Part 3: Testing
61 / 76 Unit tests ● Testing your units of code ● One class at a time ● No IO ● No setup required ● Mocking only dependenc...
62 / 76 Integration tests ● Testing your adapters ● Maybe multiple classes ● Including IO ● Some setup required ● Mocking ...
63 / 76 Acceptance tests ● Testing your application services ● Multiple classes ● Use cases ● Infrastructure stand-ins
64 / 76 System tests ● Testing your application end-to-end ● The real deal
65 / 76 Testing pyramid ● Make it well-balanced Unit Integration System Acceptance
66 / 76 Testing pyramid ● Make it well-balanced Supports development Prevents regressionSlow, brittle Fast, stable Proof o...
67 / 76 assignment/07.md ● Different types of tests
68 / 76 Acceptance tests ● Use infrastructure stand-ins Acceptance test test the application layer
69 / 76 Persistence FileBased InMemory Port Adapters
70 / 76 MeetupRepository FileBasedMeetupReposit ory InMemoryMeetupReposit ory Domain Infrastructure implements implements
71 / 76 assignment/08.md ● A test double for the Persistence port
72 / 76 assignment/09.md ● An acceptance test for the application layer
73 / 76 assignment/10.md ● Notifications
74 / 76 A well-balanced test suite ● Adapters can be easily replaced ● Test suite is fast ● Feedback is quick ● Small amou...
75 / 76https://matthiasnoback.nl
76 / 76 Questions? Feedback? info@matthiasnoback.nl @matthiasnoback https://joind.in/talk/89f5b
Layers, ports and adapters
Upcoming SlideShare
Loading in …5
×

Layers, ports and adapters

349 views

Published on

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

Published in: Software
no profile picture user

  • Be the first to comment

Layers, ports and adapters

  1. 1. 1 / 76 Advanced Application Architecture Layers, Ports & Adapters Matthias Noback info@matthiasnoback.nl
  2. 2. 2 / 76 Slides are on Twitter ● @matthiasnoback ● https://twitter.com/matthiasnoback
  3. 3. 3 / 76 https://github.com/matthiasnoback/layers-ports-and-adapters-workshop/
  4. 4. 4 / 76 Demo time http://localhost:8080
  5. 5. 5 / 76 Architecture ● Application-level design ● An application’s relation with other systems ● Framework/library/vendor choices? ● Big design upfront?
  6. 6. Frameworks dictate the structure of your project
  7. 7. High-level structural elements ● Models/entities ● Controllers ● Views/templates ● Migrations ● Configuration
  8. 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. 9. The effects of a framework-driven architecture ● Implicit use case scenarios ● Implicit connections to actors ● Coupling to the framework
  10. 10. Why bad? ● Scenarios are interrelated (legacy spaghetti) ● Domain logic is mixed with infrastructure logic ● Impossible to switch frameworks
  11. 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. 12. Part 1: Layers
  13. 13. 14 / 76 Traditional layering view controller model
  14. 14. 15 / 76 Layers ● Help you protect what's in a deeper layer
  15. 15. 16 / 76 Layers ● Allow you to define dependency rules
  16. 16. 17 / 76 Layers ● Define the right place to put things
  17. 17. 18 / 76 Layers ● Horizontal division (as opposed to...)
  18. 18. 19 / 76 Use cases ● Vertical division
  19. 19. 20 / 76 Layers: combine both
  20. 20. 21 / 76 Cohesion – A basic set of layers ● Infrastructure ● Application ● Domain
  21. 21. 22 / 76 Layer conventions Domain model: ➤ Entities ➤ Value objects ➤ Domain services ➤ Factories Business logic Decisions Data State Behavior ● Domain layer
  22. 22. 23 / 76 Layer conventions ➤ Find an object ➤ Change something ➤ Notify something ➤ Get some information Use cases Orchestration ● Application layer
  23. 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. 24. 25 / 76 assignment/01.md ● Layers
  25. 25. 26 / 76 Part 2: Ports & Adapters
  26. 26. 27 / 76 Messaging is the big idea
  27. 27. 28 / 76 Ports (cohesion) User interface Persistence ● Web, CLI, test client, messages, database queries
  28. 28. 29 / 76 Ports... And adapters HTTP SQL ● Translation
  29. 29. 30 / 76 Hexagonal architecture User interface Persistence
  30. 30. 31 / 76 Ports... And adapters (De)serialization, translation, structural validation HTTP SQL
  31. 31. 32 / 76 assignment/02.md ● Ports
  32. 32. 33 / 76 Port Adapters ● ...in the Infrastructure layer
  33. 33. 34 / 76 Application services ● ... in the Application layer
  34. 34. 35 / 76 Domain model ● … in the Domain layer
  35. 35. 36 / 76 Application services ● Delivery-mechanism agnostic
  36. 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. 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. 38. 39 / 76 assignment/03.md ● Input adapters
  39. 39. 40 / 76 Validation ● At multiple levels: ● Structural validation of messages ● User-friendly input validation ● Domain invariant protection
  40. 40. 41 / 76 Structural validation ● In the infrastructure layer: ● Form keys ● JSON schema
  41. 41. 42 / 76 User-friendly input validation ● Also in the infrastructure layer ● Usability concern ● Prevent problems later on ● Localized, translated ● Friendly
  42. 42. 43 / 76 Domain invariant protection ● In Application and Domain layer ● Domain objects: always valid ● Valid state ● Valid state transitions
  43. 43. 44 / 76 assignment/04.md ● Input validation
  44. 44. 45 / 76 Application services ● Transactional consistency
  45. 45. 46 / 76 Coupling – The Dependency rule ● Layers should only depend on deeper layers
  46. 46. 47 / 76 Coupling – The Dependency rule ● Infrastructure ● Application ● Domain
  47. 47. 48 / 76 Dependency inversion principle ● Classes should always depend on things that are more abstract
  48. 48. 49 / 76 Dependency inversion principle low-levelconcrete class specific abstract interface generic high-level
  49. 49. 50 / 76 Dependency inversion principle use
  50. 50. 51 / 76 Dependency inversion principle use implement
  51. 51. 52 / 76 Coupling is about dependencies in code ● Use Dependency Injection
  52. 52. 53 / 76 assignment/05.md ● Output adapter
  53. 53. 54 / 76 Incomplete entity ● A Meetup without an ID…
  54. 54. 55 / 76 Database-generated ID ● Faux-auto increment (check out the code)
  55. 55. 56 / 76 Alternative: UUID ● Universally Unique Identifier ● “7d7fd0b2-0cb5-42ac-b697-3f7bfce24df9”
  56. 56. 57 / 76 assignment/06.md ● A hidden dependency on the persistence mechanism
  57. 57. 58 / 76 Alternative: Sequence ● MeetupId encapsulates the type of ID used
  58. 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. 59. 60 / 76 Part 3: Testing
  60. 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. 61. 62 / 76 Integration tests ● Testing your adapters ● Maybe multiple classes ● Including IO ● Some setup required ● Mocking no dependencies
  62. 62. 63 / 76 Acceptance tests ● Testing your application services ● Multiple classes ● Use cases ● Infrastructure stand-ins
  63. 63. 64 / 76 System tests ● Testing your application end-to-end ● The real deal
  64. 64. 65 / 76 Testing pyramid ● Make it well-balanced Unit Integration System Acceptance
  65. 65. 66 / 76 Testing pyramid ● Make it well-balanced Supports development Prevents regressionSlow, brittle Fast, stable Proof of effectiveness Proof of Correctness
  66. 66. 67 / 76 assignment/07.md ● Different types of tests
  67. 67. 68 / 76 Acceptance tests ● Use infrastructure stand-ins Acceptance test test the application layer
  68. 68. 69 / 76 Persistence FileBased InMemory Port Adapters
  69. 69. 70 / 76 MeetupRepository FileBasedMeetupReposit ory InMemoryMeetupReposit ory Domain Infrastructure implements implements
  70. 70. 71 / 76 assignment/08.md ● A test double for the Persistence port
  71. 71. 72 / 76 assignment/09.md ● An acceptance test for the application layer
  72. 72. 73 / 76 assignment/10.md ● Notifications
  73. 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. 74. 75 / 76https://matthiasnoback.nl
  75. 75. 76 / 76 Questions? Feedback? info@matthiasnoback.nl @matthiasnoback https://joind.in/talk/89f5b

×