- This kata is not about implementing an hexagonal architecture
- There is an architecture already in place
- This kata is about having a first-hand experience of the benefits and trade-offs of the architecture
- You can use them as flash cards, RSVP or Flipped classrom
- Concepts
- You can edit the markdown with Marp
- Hint: don't forget about writing tests!
- Check: there's no need to change the delivery. New features are automatically delivered though the web and console adapters
- Hint: the adapters should adapt the error accordingly e.g web responds with a 4xx status code
- Check: By using the outside-in mindset, tests don't need to know the specifics about the validation implementation and they can focus exclusively on its visible effects.
- Check: changing all the web urls only requires changing one line of code
Here are some ideas to try by yourself:
- Implement authentication inside your hexagon
- Log the request history with a secondary port e.g.
RequestLogRepository
- Change the primary port so that you can avoid exposing particular features in your adapters
- Segregate requests into queries and commands
- Do you see any relation between Ports and Adapters and CQRS?
- Once you've done that, can you think of new delivery strategies you can follow?
Ports and Adapters: features and architecture are decoupled so:
- I can develop features without having to be aware of the architecture, and viceversa
- I can test features without worrying about how they're delivered
Compare these options:
- Classic layered architecture
- Ports and Adapters with one adapter for each feature
- Ports and Adapters with one primary port for all features
About dependencies:
- Dependency inversion? Inversion of Control? DIP?
- DIP in the Wild