github.com/alexeyilchuk/go-app-layout

go-app-layout

Для примера взят домен простого аэроагрегатора, в котором есть такие сущности как: пассажир (Passenger), рейсы (Flight), регистрация (Registration) и бизнес-процесс регистрации на рейс (компонент FlightRegistration).

1. Организация домена в единой папке app

Данный пример является одним из вариантов реализации чистой архитектуры, которую предложил Роберт Мартин, на языке go. Есть и другие реализации, но этот подход был опробован и неплохо зарекомендовал себя.

└── internal_with_app
    └── some_lib -- какая-нибудь библиотека  
    └── app      -- доменный уровень, тут располагаются доменные сущности и бизнес-логика, которая не зависит от деталей реализации внешних зависимотей
        └── storage -- подпакет app, уровень взаимодействия с хранилищами, другими словами адаптер домена к внешним зависимостям, которые отвечают за хранение данных
            ├── postgres -- конкретные реализации postgres репозиториев
                ├── registration_repository -- конкретная реализация postgres-репозитория, который отвечает за CRUD для app.Registration 
            └── memory   -- конкретные реализации in-memory репозиториев
                ├── registration_repository -- конкретная реализация in-memory репозитория, который отвечает за CRUD для app.Registration 
        └── flight.go
        └── flight_registrator.go
        └── flight_registrator_test.go
        └── passenger.go
        └── registration.go
    └── utils  

2. Организация домена с распределением домена по пакетам models и services

└── internal_with_models
    └── some_lib -- какая-нибудь библиотека 
    └── models   -- доменный уровень, тут располагаются доменные сущности
        └── flight.go
        └── passenger.go
        └── registration.go
    └── services -- доменный уровень, тут располагается бизнес-логика   
        └── flight_registrator.go
        └── flight_registrator_test.go
    └── storage  -- уровень взаимодействия с хранилищами, другими словами адаптер домена к внешним зависимостям, которые отвечают за хранение данных
        ├── postgres -- конкретные реализации postgres репозиториев 
            ├── registration_repository -- конкретная реализация postgres-репозитория, который отвечает за CRUD для app.Registration 
        └── memory   -- конкретные реализации in-memory репозиториев
    └── utils  

Плюсы и минусы подхода №1 относительно №2

Плюсы

• Более явная индикация доменного слоя и адаптеров домена к внешнему миру
• Нет размывания доменной логики по двум пакетам, так как доменная логика может быть реализована в виде методов одной из сущностей (см. сущность Passenger)
• Нейминг более компактный, так как нет импортируемых пакетов (нет префикса с названием пакета в начале при использовании сущностей при реализации бизнес-логики)
• !Отсутсвует угроза возникновения циклических зависимостей, при усложнении домена!

Минусы

• При росте количества объектов домена и бизнес-логики пакет может быть достаточно большим, но в целом это не супер критичная вещь, можно группировать сущности и логику по файлам.