Ryan Gough
Software developer, C# by day, Erlang and JS by night.
Refactoring Hexagons
Hexagonal Architecture
- "Pure" Domain
- Reusable business logic
- Dependency Inversion
- Able to swap out external components, even UI
a.k.a "Ports and Adapters", "Clean Architecture"
Mistaeks I Hav Made
#97865 - Failing to recognise domain boundaries
#97866 - Interface obsession, or not following the Reused Abstractions Principle (RAP)
Bloated Solution
- Sub folders
- Too many tests
- Difficult to navigate
- Minimal code reuse
- Shortcuts taken...
IoC Hell
- Classes with many injected dependencies
- Only alternative implementations are mocks
- Horrible names
- Factories in factories
Software Design == Finding Useful Abstractions
Software designers win by separating things that can be considered separately, lose by separating things that must be considered together - Kent Beck
Downwards pressure on classes & methods
- Single Responsibility Principle
- Refactoring tools
- TDD
- Clean code
Microservices
Bringing small == better to a higher level?
- Big architectural possibilities
- Clear responsibilities
- "Harder" boundaries
- Move complexity don't remove it
- Increase "DevOps" responsibilities
* Compulsory "not a silver bullet" warning, not universally applicable, your mileage may vary, terms and conditions apply, the value of your investment may go up as well as down.
Big Ball Of Mud
Structured Monolith
Microservices?
Current Solution
- 3 Projects - Service, Tests and Host Application
- Closer to "Ports and Adapters" approach
- Fewer classes / interfaces
- No more IoC!
Fewer Tests, Better Coverage
Some difficulties
- Managing contracts between solutions
- Anti-corruption layers / mappings
The End
Refactoring Hexagons
By Ryan Gough
