The Hexagonal Architecture and mocks as a design technique

Now that you know about the Hexagonal Architecture and the idea of ports and adapters, we can talk about mocks as a design technique. In a nutshell, whenever mockists develop a feature (or a domain object) and notice that they need something from another place, they let a port emerge. As we saw, the port is an interface that allows the mockist to develop the remainder of the feature without being bothered by the concrete implementation of the adapter. The mockist takes this as a design activity: they reflect on the contract that the port should offer to the core of the application and model the best interface possible.

Whenever I am coding a class (or set of classes) and notice that I need something else, I let an interface emerge that represents this “something else.” I reflect on what the class under development needs from it, model the best interface, and continue developing the class. Only later do I implement the concrete adapter. I enjoy this approach as it lets me focus on the class I am implementing by giving me a way to abstract things that I do not care about right now, like the implementation of adapters.