0

We're creating a new application for an entirely new domain model (and Bounded Context) 'Appointment'. We chose to combine CQS with Hexagonal Architecture (using ports and adapters) for our new domain.

Our package structure mainly looks like this:

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

My questions:

  1. Is this package structure OK for what we're trying to achieve?
  2. We would want to see every communication to/from other domains via the AppointmentScheduleFacade interface. Cross-domain communication resides as plain method invocations (no RPC or REST) as they're not distributed.

    The facade mainly delegates to :

    • AppointmentScheduleApplicationService.java for model modification
    • AppointmentScheduleQueryService.java for passing data to other domains.

Is this setup OK? Or should an other domain correspond directly with Application and QueryService?

Vahid Farahmandian
  • 5,079
  • 5
  • 38
  • 54
user2054927
  • 849
  • 1
  • 10
  • 27
  • 2
    CQS is just the way you distinguish your methods in a class to commands that return void and queries that return something. Do you mean CQRS may be? – Alexey Zimarev Jul 16 '16 at 10:34
  • My question are more related to: 1) does my package structure makes sense (hexagonal)? 2) Is it OK to provide a Facade that is only used to interact with other domains and mainly delegates operations to Application and Query Service? Any suggestions are always welcome! – user2054927 Jul 16 '16 at 11:50

1 Answers1

0

your structure seems to be fine, but of course it depends on how you use it. Hexagonal architecture is not just a matter of folder structure.

About communication between modules or contexts, I suggest you to strive for achieving less coupling possible: you can do that using a message bus where you publish your domain events, and other domains can retrieve those messages and do whatever they need. So from one module you don't need to know other modules, you just need to know the bus and to be able to read a message from that bus (serialized in json format, typically).

Modules publish and subscribe to events: is dependency inversion principle, but at an architecture level.

If you post some code example, I could be more explicit.

Good luck!

rastafermo
  • 358
  • 1
  • 3
  • 12