Понимание концепции шестиугольных портов и адаптеров на примере

Question

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

public interface IPerson
{
   string GetName();
}

и Адаптер для класса, реализующего интерфейс:

public class Person : IPerson
{
  //Implementation of GetName here
}

Я понимаю концепцию шаблона Банды четырех Адаптеров.Однако я не понимаю, как это вписывается в DDD.

Это действительно помогло бы мне увидеть простой пример кода в контексте DDD.

Answer 1

TLDR: порты и адаптеры не похожи на разъемы USB и разъемы USB.Адаптеры - это кабели USB-Lightning.

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

Это немногоклубок, особенно потому, что

1. Сами по себе картины не рассказывают историю
2. Картины очень похожи на лук и рассказывают историю по-другому.

Два вложенных многоугольника (традиционно два шестиугольника) представляют логические границы.«Базовая логика домена полностью живет внутри внутреннего многоугольника. За пределами внешнего многоугольника находится реальный мир: шины сообщений, базы данных, пользовательский интерфейс, файловые системы и т. Д. Все эти вещи имеют порты.

ДляНапример, в интерактивной оболочке ваши порты - это stdin, stdout, stderr.

Адаптеры - это то, что мы устанавливаем, потому что порты на внешней границеи порты на внутренней границе не совпадают. Моя модель домена не говорит на SQL, поэтому у меня есть адаптер, который находится между моей моделью домена и клиентом базы данных. Моя модель домена не поддерживает форматирование терминала, поэтому у меня естьадаптер, который находится между моделью домена и интерактивной оболочкой.

Часть волшебства в том, что мы можем объединять новые компоненты, меняя адаптер. Моя логика домена также не знает о представлении HTML, ноЯ должен иметь возможность заменить адаптер интерактивной оболочки на адаптер веб-браузера и дать пользователям новый способработать с моделью предметной области.Я должен иметь возможность переключать стратегии постоянства, используя новый адаптер для связи с новым устройством стабильного хранения.

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

Я не понимаю, как это вписывается в DDD.

Одна из причин, по которой трудно понять, какэто подходит;Порты и адаптеры это сантехника, а не доменная модель.Все биты, которые оправдывают работу выполнения анализа домена, живут внутри внутреннего многоугольника.

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

Рекомендуемое чтение: * Архитектура портов и адаптеров @ c2 wiki

Answer 2

Адаптер для класса, который реализует интерфейс

Не всегда.Это верно для ведомой стороны, но для стороны водителя адаптер - это программный компонент, который использует интерфейс (называет его методы).

Я написал концептуальную статью о портах и ​​шаблоне адаптера (шестиугольная архитектура):

https://softwarecampament.wordpress.com/portsadapters

Там вы можете прочитать об этом.

Сегодня вечером я прочитал множество объяснений, однако я не нашел пример кода.

Некоторый код, который я только что изобрел, чтобы объяснить вам, что такое порт и что такое адаптер на практике:

В интернет-магазине порт драйвера может быть:

    public interface ForManagingShoppingCart {
        public void addProductToShoppingCart ( String productId );
        // ... more methods ...
    }

Адаптер драйвера может быть контроллером, который принимает пользовательские запросы от интерфейса пользователя и вызывает методы порта драйвера:

    public class ShoppingCartController {

        private final ForManagingShoppingCart forManagingShoppingCart;

        // Injects port in the constructor
        public ShoppingCartController ( ForManagingShoppingCart forManagingShoppingCart ) {
            this.forManagingShoppingCart = forManagingShoppingCart;
        }

        // Method that executes when user selects a product in the view and clicks the "add product" button
        public void addProductOnClick ( String productId ) {
            this.forManagingShoppingCart.addProductToShoppingCart ( productId );
        }

    }

Если приложение отправляет вам электронное письмо, когда высделать заказ на покупку, управляемый порт может быть:

    public interface ForNotifyingClients {

        public void sendPurchaseOrderConfirmation ( String recipient );

    }

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

Я понимаю концепцию шаблона Банды четырех.

Шаблон адаптера подходит, потому что вы переводитеперенести методы интерфейса в методы интерфейса системы электронной почты.

    public class EmailNotificationAdapter implements ForNotifyingClients {

        private final EmailSystem emailSystem;

        // Inject the email system interface you want to use in the adapter constructor
        public EmailNotificationAdapter ( EmailSystem emailSystem ) {
            this.emailSystem = emailSystem;
        }

        // Implements the method using the email system to send an email
        @Override
        public void sendPurchaseOrderConfirmation ( String recipient ) {
            // ...code that sends an email to the recipient using this.emailSystem
        }

    }

Я не понимаю, как это вписывается в DDD ... Это действительно помогло бы мне увидеть простой пример кода в контексте DDD.

DDD хорошо вписывается в гексагональную архитектуру:

• Уровень приложения и модель домена будут находиться внутри шестиугольника.
• API служб приложений будут портами драйверашестиугольника.
• Уровень представления (UI) будет адаптером драйвера.
• Уровень инфраструктуры будет содержать управляемые адаптеры.
• Когда нужен прикладной уровень или модель предметной областичтобы иметь дело с технологией, они определяют управляемый порт, который должен реализовывать управляемый адаптер в инфраструктуре.