Правильно ли я понял порты и адаптеры / шестиугольную архитектуру? - PullRequest
Новая
       52

Правильно ли я понял порты и адаптеры / шестиугольную архитектуру?

0 голосов
/ 22 января 2019

Архитектура портов и адаптеров направлена ​​на создание разобщенного кода.Уровень домена напрямую не зависит от уровня инфраструктуры, а зависит от порта (интерфейса), а реализация порта находится на уровне инфраструктуры, верно?

Структура моей папки будет такой:

  1. Проект для моего пользовательского интерфейса

  2. Проект для ядра приложения, который содержит прикладную службу, доменные службы и доменные модели.

  3. Проект для портов: он содержит строго интерфейсы.

  4. Проект для инфраструктуры, и у меня там есть папка постоянства.

Механизм доставки можно переключить (из консольного приложения ввеб-приложение ...) и ядро ​​все равно будет работать.

То же самое для инфраструктуры, я мог бы использовать Entity Framework один раз, а затем переключиться на более привлекательный, не вызывая изменений в ядре.

Пока все хорошо, или я что-то упустил по пути, или я упустил очень базовое понимание архитектуры?

Теперь код мудрый:

Если яу меня есть консольное приложение, где я должен набрать команду, и она создает клиента.

Класс из Службы приложений, найденный в проекте Core.Он использует внедрение зависимостей для доступа к реализации IPersistence.

    public class AddNewCustomer
    {
        private readonly IPersistence _persistence;

        public AddNewCustomer(IPersistence persistence)
        {
            _persistence = persistence;
        }

        public bool addToDb(customer customer)
        {
            return _persistence.add(customer);
        }

    }

Интерфейс в проекте порта.

    public interface IPersistence
    {
        bool add(Customer customer);
    }

Реализация в интерфейсе проекта.

    public class Persistence: IPersistence
    {
        public bool add(customer customer)
        {
           //inserts into DB
        }
    }

Предполагается, что проект порта должен быть строго связан с интерфейсами?Как вы структурируете (структуру папок) ваш проект портов и адаптеров?

1 Ответ

0 голосов
/ 24 января 2019

Пока все хорошо, или я что-то упустил по пути, или я пропустил самое базовое понимание архитектуры?

Я постараюсь правильно выразить себя. Надеюсь, это поможет.

Архитектура портов и адаптеров направлена ​​на создание развязанного кода.

Это правда. Но это не главная цель "per se". Это способ достижения главной цели, которая заключается в том, чтобы иметь возможность тестировать приложение изолированно от внешних устройств (аппаратных средств, программного обеспечения, людей и т. Д.), Которые выходят за рамки приложения.

Уровень домена не зависит напрямую от уровня инфраструктуры, вместо этого это зависит от порта (интерфейса) и реализации порта находится на уровне инфраструктуры, верно?

Вы говорите о слоях. Гексагональной архитектуры нет. Это просто говорит о том, что у вас есть приложение (шестиугольник) с портами, через которые внешние приложения реального мира (так называемые актеры) взаимодействуют с приложением. Порты принадлежат приложению (которое не зависит от технологии), а взаимодействие порт-субъект осуществляется через технологически зависимый адаптер.

Проект для ядра приложения, который содержит Приложение Сервис, доменные сервисы и доменные модели.

Здесь я просто хотел бы отметить, что шаблон гексагональной архитектуры ничего не говорит о внутренней структуре приложения (шестиугольник).

Механизм доставки можно переключить (из консольного приложения в Интернет приложение ...) и ядро ​​будет работать так же.

Все в порядке. Консоль и веб-приложения - это адаптеры, которые управляют приложением. Они используют порты драйвера (порты, которые предоставляют функциональность приложения внешним субъектам).

Я мог бы использовать платформу сущностей один раз, а затем переключиться на щеголеватый без изменения ядра.

Всё в порядке. Это могут быть адаптеры для постоянного порта, который является управляемым портом (управляемый адаптер реализует управляемый порт для взаимодействия с внешним субъектом).

Предполагается, что проект порта должен быть строго связан с интерфейсами? Как Вы структурируете (структуру папок) свои порты и адаптеры проекта?

У меня есть «модуль java 9» для шестиугольника (вы называете его Core). И порты являются пакетами модулей, которые я экспортирую. Каждый порт представляет собой пакет с сервисным интерфейсом, определяющим операции порта. Но у вас может быть больше классов (представляющих аргументы операции, средства отображения, если вы не хотите открывать внутренние объекты для внешнего мира, ...). Реализация зависит от вас.

Структура моей папки (java-пакетов):

Hexagon:

[имя приложения] .hexagon.internal = внутренняя часть приложения

[имя-приложения] .hexagon.driver. [Имя-порта-драйвера] = один или каждый порт драйвера (API приложения)

[имя-приложения] .hexagon.driven. [Имя-управляемого-порта] = один или каждый управляемый порт (SPI приложения)

Адаптер между портом и актером с использованием технологии:

[имя-приложения] .adapter.driver. [Имя-порта-драйвера]. [Имя-субъекта]. [Технология] = один для каждого адаптера драйвера

[имя-приложения] .adapter.driven. [Имя-управляемого-порта]. [Имя-субъекта]. [Технология] = один для каждого управляемого адаптера

Я написал статью о гексагональной архитектуре, где я объясняю шаблон, и я собираюсь опубликовать пример реализации. Если вы хотите прочитать это, вот ссылка:

https://softwarecampament.wordpress.com/portsadapters

Надеюсь, это поможет.

...