Сторонний поставщик мыла и Чистая Архитектура

Question

Мы разрабатываем приложение с парадигмой чистой / гексагональной архитектуры, но мы новички в этом. Итак, у нас есть несколько вопросов.

Сценарий таков:

• У нас есть внешний сервис SOAP, который предоставляет нам некоторую информацию о "Entity" и связанный с ней "Документ"
• Для каждой организации заявка должна:
  • хранить все документы сущностей на CMS (контент и некоторые атрибуты сущностей)
  • хранить сущность в DDBB с сохраненной ссылкой на документ

Давайте посмотрим на наше первоначальное решение на Java-подобный подход:

Сущность и документ

class Entity {
  private String id;
  // other attributes ... 
  private Document xml; 
  private Document pdf; 
  // some business logic
}

class Document {
  private long id;
  //other attributes
  InputStream getStream() {...}
}

FRepositori абстракция на уровне домена

class EntityRepositori {
  Entity create(Entity entity);
  ...
}

DocumentRepositori абстракция на уровне домена

class DocumentRepositori {
  Document create(Document document)
  ...
}

Абстракция ExternalService на уровне приложений для службы SOAP

class ExternalService {
  List<Entity> getEntities();
  ...
}

Реализация варианта использования на уровне приложений

class IncorporateEntityUseCase {
  IncorporateFUserCase(EntityRepositori, DocumentRepositori, ExternalService){...}
  void incorporate() {
    List<Entity> entities = externalService.getEntities();
    for (Entity entity : entities) {
        Document xml = dRepository.create(entity.getXmnl());
        Document pdf = dRepository.create(entity.getPdf());
        entity.setXml(xml);
        entity.setPdf(pdf);
        entityRepository.create(entity);
    }
  }
}

Вопросы

1. Что касается ExternalService, правильно ли определять его абстракцию с помощью Entity и Document или он должен возвращать некоторый ValueObject, который реализации UseCase преобразуют в сущности?
2. О документе, мы должны спроектировать его как сводный корень и исключить ссылки на объекты документа из сущности?

Answer 1

Краткая версия: попробуйте думать о любой из ваших сторонних служб просто как о другом шлюзе (или "хранилище").

Просто столкнувшись с этим точно таким же вопросом сам (представьте себе систему, в которой пользователи загружают документы как часть более крупного предметного объекта "Анкета", а затем анализируют их), я в итоге пошел на подход, который использует внешний API / парсер (или в вашем случай, сторонний сервис SOAP) на самом деле, просто еще один шлюз. То есть: файлы передаются (через загрузку веб-страницы), отправляются с контроллеров webapi на интерактор, передаются через шлюз (в настоящее время в виде потока, но так же, как они могут передаваться в шлюз / хранилище db).) - где они обрабатываются, а результат возвращается как модель сущности. Таким образом, у Interactor есть шлюз БД и шлюз анализатора документов, которые возвращают модели Доменов, которые можно использовать.