Путаница во взаимодействии с другими доменами

Question

Мы создаем новое приложение для совершенно нового domain model (а также Bounded Context) 'Appointment". Мы решили объединить CQS с Hexagonal Architecture (используя порты и адаптеры) для нашего нового домена.

Наша структура пакета в основном выглядит следующим образом:

.appointments
  .application
    .command
    .representation
    - AppointmentScheduleApplicationService.java
    - AppointmentScheduleQueryService.java
  .domain.model
  .port.adapter
    .integration
    .persistence
    .web
    .service
      - AppointmentScheduleFacade.java

Мои вопросы:

1. Является ли эта структура пакета приемлемой для того, чего мы пытаемся достичь?

2. Мы хотели бы видеть каждое сообщение в / из других доменов через AppointmentScheduleFacade интерфейс. Междоменная связь осуществляется как простые вызовы методов (без RPC или REST), поскольку они не распределены.

   Фасад в основном делегирует:

   • AppointmentScheduleApplicationService.java для модификации модели
   • AppointmentScheduleQueryService.java для передачи данных в другие домены.

Все в порядке? Или другой домен должен напрямую соответствовать Application а также QueryService?

Answer 1

Ваша структура кажется хорошей, но, конечно, это зависит от того, как вы ее используете. Гексагональная архитектура - это не только структура папок.

Что касается связи между модулями или контекстами, я предлагаю вам стремиться к достижению меньшего возможного связывания: вы можете сделать это, используя шину сообщений, где вы публикуете события своего домена, а другие домены могут извлекать эти сообщения и делать все, что им нужно. Таким образом, из одного модуля вам не нужно знать другие модули, вам просто нужно знать шину и иметь возможность читать сообщение с этой шины (обычно сериализованное в формате json).

Модули публикуют и подписываются на события: это принцип инверсии зависимостей, но на уровне архитектуры.

Если вы опубликуете какой-нибудь пример кода, я мог бы быть более явным.

Удачи!