Summary

Did you succeed to create a nice OO application by using multi-level architecture?
We think that is not possible and multi-level architecture leads to procedural coding.

Alistair Cockburn introduced Hexagonal architecture that is more suitable to follow OO design. Hexagonal architecture (aka ports and adapters) is a generalization of two fundamental concepts that allows separation of business logic from infrastructure in the big as in the small.

It is a tool that can serve many goals

Business oriented tests/spec

Reducing conditionals

Centralisation of business rules (OnceAndOnlyOnce)

DecideLate (regarding frameworks and tools) as in Lean, Real Options

Duration

40 minutes

Detailed Schedule

A concrete, real world, exemple of how layers forces us to duplicate conditionals, write technical facing tests and prevents us from centralising a business rule in one place.
We explain and show a solution that illustrates the concept
General explanation of Hexagonal architecture
Do It Yourself (DIY) on the User-side API, refactoring the code to respect HA, rewrite the tests to a new level of business orientation https://github.com/martinsson/hexagonal-UI
Example of data-site api using dependency inversion
A concrete example of abstracting away the data-side api
How does it support, DDD, Screaming architecture?
Where is this pattern present already?

What you will learn?

How to

separate Business rules from infrastructure

write unit tests that can be used to communicate with non technical stakeholders

spot and remove a very subtle flavor of duplication

postpone technical decisions to when you know more.

Pre-requisites

A few years of programming experience. Basic notions of the callback mechanism and dependency inversion will be useful.