A simple kata to live-code with Alistair about Hexagonal Architecture
-
Test-drive the design of our 1st port (i.e. the intention, represented in C# with an interface: IRequestVerses and a first method: GiveMeSomePoetry()).
- This very first version of the business logic (i.e.: the PoetryReader type) returns an hard-coded result.
- The left-side adapter is both the unit test framework and the test calling the port
-
Write another acceptance test with the simplest possible right-side adapter: a stub for the new right-side port: IObtainPoems and its unique GetAPoem() method/verb.
-
Write another acceptance test to test-drive the usage of a new Console (app) adapter
- Here, we need to mock the Console.WriteLine calls by introducing a ICanWriteLines strategy. This mock will assert that it has received the proper call after GiveMeSomePoetry is called.
- Proper time to illustrate the 3 steps initialization of the Hexagonal Architecture (i. Instantiate the "I need to go out" ports and adapters ii. Instantiate the PoetryReader hexagon iii. Instantiate the "I need to go in" ports and adapter)
- Introduce here an "hexagon" wrapper onto the business logic (to explicit the architectural pattern for the years to come?)
-
Write a CONSOLE application (embedding the right-side mock) to get end-users feedbacks about the way we will soon ask questions to the system
- Alistair's feedback (playing the end-user) is that we need to have other poems than the hard-coded one.
-
Test drive a right-side PoemFileAdapter that will return the content of a file knowing its path (file being: Rimbaud.txt).
The application is now structurally complete (with left and right-side adapters). We can either:
- Add a CycleThroughPoemsAdapter (that will leverage on the Poetry.json file)
- Test drive a __JSON (left-side) adapter and create a Web API project to gather end-users feedbacks
- Replace the PoemFileAdapter and CycleThroughPoemsAdapter with a DatabaseAdapter
- Introduce a new API/Verb for the 1st port: GiveMeLines(int linesCount)