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.

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

×