0

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

The scenario is:

  • We have an external SOAP service who gives to us some "Entity" information and related "Document"
  • For every Entity the application must:
    • store all the Entity Documents on a CMS (content and some Entity-attributes)
    • store Entity on DDBB with stored Document reference

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?
Leo
  • 75
  • 1
  • 8
  • 2
    You know, single letter variables in code are already a big no-no. I would use proper contextual names in your problem description instead of vague "F" and "D". As written I see little chance of anyone actually having a clue what is in your brain that you did not commit to text yet. – Gimby Mar 18 '16 at 10:15
  • Sorry @Gimby ! You are right – Leo Mar 18 '16 at 10:35

1 Answers1

1

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.

Dale Holborow
  • 520
  • 3
  • 18
  • Thanks @dale-holborow, we were confused about how Service Gateway could create entities instances when Repository Gateway knew anything about they and where we should manage possible duplicates (i.e. two calls to getEntities() returns at least one concrete entity). – Leo Mar 30 '17 at 11:34