CODEWITHSUNDEEP
architecturedomain-driven-designclean-architecturehexagonal-architecture
Leo
Leo

Reputation: 75

Third party soap provider & Clean Architecture

We are designing an application with clean/hexagonal architecture paradigm but we are newbies on this. So we have some questions.

The scenario is:

Lets see our initial solution on java-like approach:

Entity and Document 

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 abstraction at Domain Layer

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

DocumentRepositori abstraction at Domain Layer

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

ExternalService abstraction at Application Layer for the SOAP service

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

An Use Case implementation at Application Layer

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);
    }
  }
}

Questions

  1. About ExternalService, it is correct to define its abstraction with Entity and Document or must it returns some ValueObject that UseCase implementations will transform to entities?
  2. About Document, must we design it as an aggregate root and eliminate Document object references from Entity?

Upvotes: 0

Views: 1224

Answers (1)

Dale Holborow
Dale Holborow

Reputation: 580

Short version: try thinking about any of your 3rd party services as simply another Gateway (or "repository").

Having just come across this exact same question myself (think a system where users upload documents as part of a larger domain object "Questionnaire" and then parse them), I ended up going with the approach that the external api / parser (or in your case, 3rd party SOAP service) is really, just another Gateway. Ie: the files are passed in (via webpage upload), send down from the webapi controllers to the interactor, transmitted out through a gateway (currently as a stream, but in the same way that they might be passed to a db gateway/repository) - where they are processed, and the result returned as an Entity model. So the Interactor has a db gateway and a document parser gateway, both of which return Domain models that are usable.

Upvotes: 2

Related Questions