Hexagonal architecture - a simple use case

Question

I've been reading a lot a bout hexagonal architecture and I do get most of the concepts (well, I hope I do), I didn't find any example of that architecture use-case wise.

Let's say that my application domain model is to make people drunk. The whole business logic is contained in Person class which resides in the domain layer.

class Person
{
    private $name;
    private $age;

    function __construct($name, $age)
    {
        $this->age  = $age;
        $this->name = $name;
    }

    public function drink()
    {
        if ($this->age < 18) {
            echo $this->name . ' cant drink';
        }

        echo $this->name . ' drinks tequila';
    }
}

Domain layer also contains a PersonRepository

interface PersonRepository
{
    public function findPersonByName($name);
}

implemented by:

class DoctrinePersonRepository implements PersonRepository
{
    public function findPersonByName($name)
    {
        // actual retrieving
    }
}

Let's assume I want to make a person drunk by accessing: GET /person/johnDoe/drink. Should I create a use case like:

class MakePersonDrinkCase
{
    /**
     * @var PersonRepository
     */
    private $personRepository;

    function __construct(PersonRepository $personRepository)
    {
        $this->personRepository = $personRepository;
    }

    function makePersonDrunk($name)
    {
        $person = $this->personRepository->findPersonByName($name);

        if ($name) {
            throw new \Exception('Person not found');
        }

        $person->drink();
    }
}

and call it from the controller? Should this mentioned case reside in domain layer or application layer? What is a port and adapter in this case? What if I want to have to ways of getting this person drunk - one from GET request, and other from some php console person:drink John CLI command? How should I structure my app?

Answer 1

TL;DR: I think that from a DDD point of view, you're basically right, but in order to be an Hexagonal design, you should be able to register or expose your use-cases in your primary ports: web, console or "usage" as @chris-f-carroll suggests.

I currently work in a big Java8 codebase project and we have structured our application following the principles of Clean Architecture/Vertical Slicing and CQRS. We have an Hexagon with 6 ports: web, console, database, scheduling, queues and email.

In order to initialize our app, we create all the required adapters and we use them to create our app instance. Then our app's modules explicitly register their use-cases on the primary port adapters. Finally we start our primary port adapters and the app is running.

Alistair Cockburn tells that "A port identifies a purposeful conversation". In our case, as our design implies CQRS, our purposeful conversation between our application and the HTTP protocol is about exposing Queries and Commands (our use-cases).

That's the reason for having expose(uri, query) or expose(uri, command) methods in our web port instead of get(uri, handler), post(uri, handler), put(uri, handler), delete(uri, handler), etc.

How these queries and commands are exposed (i.e. as HTTP GET or POST) is an implementation detail of the web port adapter that my hexagon needs not to know.