Secondary (Outgoing) Ports with a CommandDispatcher pattern....?

[jmahmud]

Hi

I was wondering if anyone can suggest whether I'm barking up the wrong tree here....

So understanding that Ports in the Hexagonal Pattern is the way in which to interact with the Domain of a system - there seems to be a sub-categorisation in some discussions of:

• Primary Ports (Incoming) - i.e. the interfaces which allow an adapter (like a UI/MessageHandler) to interact with the Domain
• Secondary (Outgoing) - i.e. the interfaces which allow the domain to communicate back to another adapter for another external or I/O boundary (i.e read/writing to a database or HTTP API call etc)

So as Brighter documentation suggests, the invocation of the port to interact with the domain can be separated via the CommandProcessor/Dispatcher pattern in order to maintain pure behaviour-oriented definitions of interactions as well as all the other benefits of the pattern - but the discussions and examples all seem to relate to Primary Ports.

So my question, is whether this idea can/should be applied to secondary ports - or would this be over-engineering? Using an example:

• OrderController (HTTP API)
  • POST order
  • creates a Command: CreateNewOrder
• CreateOrderHandler: (via Brighter or a Dispatcher)
  • Creates an Order Domain Entity from the CreateNewOrder command
  • Needs to save to a DB (interactes with a IOrderRepository.Save(Order))
  • Publishes some Domain Event (OrderCreatedEvent) - may even outbox this...

So could the IOrderRepository actually be replaced by: a SaveOrderCommand, using the Dispatcher again to dispatch to a SaveOrderHandler which is actually an implementation of some SqlSaveOrderHandler abstracting saving to DB etc...

Appreciate there may not be a straightforward answer to this - but interested in anyone's opinion on this...

Thanks
Josh

[preardon]

Hi @jmahmud, I feel you are over complicating things, while your repositories are secondary I would ask why you would modularise this?

Personally I would do what you said above, you could even look at your entities creating the Created event, I.e. when you make a change to your Entity in your repository it crease an event.

keep in mind that you want your database updates and eventing to happen inside of the same transaction (This is where the outbox comes in) so you can ensure that they both happen together or fail together.

Hope this helps

[jmahmud]

Hi @preardon - thanks for this, yeah it's very useful to get some feedback on this, as I was trying to rationalise this part of the interaction, and it felt over-engineered (which is why I thought of asking). It is interesting that the domain event and the update to the entity are considered the same atomic operation (which makes sense) - I would would it be considered good practice to have a domain event being published from within the repository? Or just have a higher level process (i.e. the handler, or service) which controls the overall transaction and saving to db & event publish?

[preardon]

Personally I do it from the domain entity, for example (assuming you have entity update tracking)

Get the order from your repository,
Call UpdateStatus on your retrieved entity, and have that call inside your domain entity create the event, this creates a really nice pit of success as you can't update the status without creating the "NewOrderVersionEvent" and they can be easily committed to your database is the same transaction.

Hope this helps

[jmahmud]

Thanks again @preardon - I guess I have one other complication here in my model/domain that I was attempting to do in a purest way:

• I have the concept of different types of Orders, so for example (this is also more of analogy of the real scenario I have):
  • DeliveryOrder
  • PickupOrder
• The reason of having this separation is becasue following a State(-like) design pattern, data and state (and more importantly State transitions were different across the two:
  • DeliveryOrder States: (OrderReceived, OrderAccepted, ReadyForCollection, OrderTakenByDriver, OrderDeliveredByDriver, OrderCompleted)
  • PickupOrder States: (OrderReceived, OrderAccepted, ReadyForCollection, OrderPickedUp, OrderCompleted)
• As such, I actually have as part of my domain model an actual State Machine(s): IOrderStateMachine<T>:
  • IOrderStateMachine<DeliveryOrder>
  • IOrderStateMachine<PickupOrder>
• The implementations of these define the states, the triggers between them, and invokes handlers when in one state that decides which trigger to invoke...

So I what want in a CreateOrderCommandHandler is:

• Asking the Dispatcher to actually invoke a CreateOrderCommandHandler<T>
• CreateOrderCommandHandler<T>.Handle(CreateOrderCommand<T> command) would actually:
  • get the appropriate statemachine
  • invoke the state machine for the given state being handled - invoking some sort of internal StateHandler
  • The StateHandler would call out to varios other things - the Secondary Ports etc and execute real domain logic of whether the Order could transition to the next state...
  • Save the Order (with new state)
  • Publish the new State event (as you say potentially from within the Domain entity itself)

Again, the reason for raising this (sorry to go into so much detail) is becasue I began with implementing a strict domain, and wanted to model what made sense, and now running into difficulty invoking the domain from the 'adapter'/'application' and want to use Brighter to try and achieve this, but want to make sure I've not confused things...

Thanks
J

[preardon]

@jmahmud if you'de be willing to Collaborate, I'de pair with you on a sample to ensure it meets your needs

[jmahmud]

Hey @preardon - thanks again for your help - I have a more general question which I think you may have an opinion on....
Given the scenario:

• I have a controller on an API with POST /order
• the PostOrder controller formulates a command: AcceptOrderCommand (with a domain model of Order)
• I use Brighter to handler the command/dispatch to a AcceptOrderCommandHandler
• in the AcceptOrderCommand, I have the concept of whether the order can be 'accepted' which depends on checking various other things (checking of other related orders, checking of some details in the order - like whether items exist etc)
• so that 'acceptance' logic we've decided to move to a Domain Service named: IOrderAcceptanceService as it is vital domain logic.
• IOrderAcceptanceService will be injected into the AcceptOrderCommandHandler constructor
• we will have the AcceptOrderCommandHandler.Handle() still beging/commit/rollback transaction, as well as Dispatching a Domain Event after the acceptance logic if run as well as saving the Order domain entity.

`async Task Handle(AcceptOrderCommand command, CancellationToken token = default(CancellationToken))
{
_unitOfWork.BeginTransaction(cancellationToken);
try
{
var order = command.Order;

        _orderAcceptanceService.AcceptOrder(order);  // will end up calling order.Accept() or order.Deny()
        
        _orderRepository.Save(order);

        DispatchAcceptedOrDeniedEvent(order);

        _unitOfWork.Commit(cancellationToken);
    }
    catch (Exception ex)
    {
        _unitOfWork.Rollback(cancellationToken);
    }

}`

So the question is, (thinking of boundary/controller/entity separation) - would be be good practice to have tests for the AcceptOrderCommandHandler and NOT to fake/mock the Domain Service of IOrderAcceptanceService or have separate tests for the handler and the service? Was thinking about the dependancy on Brighter as well in the tests as well being a hindering factor potentially....

I am basically considering my AcceptOrderCommandHandler as the usecase, and see that all tests could be wrapped up by testing this as a unit.... however, I have separated out the logic of acceptacne into a domain service, thereby making the argument that that could have separate concrete implementations thus deserving it's own set of tests....

P.S. - I don't know why the markdown above has gone all haywire, but hopefully it's readable enough...

[preardon]

Hey @jmahmud

I usually do my tests at the handler level as I believe it can lead to less brittle tests and you are testing the entry points and results. This being said I may have TDD'd the acceptance service so there might be some lying around for that.

Realistically are you ever going to use this domain service outside of a handler? If not your handler coverage should cover your scenarios.

Happy to chat further if you would like

[jmahmud]

Yes this was my thinking too @preardon - that's interesting to hear as I guess you could argue that the same tests could be run if Brighter was exchanged with another command/dispatcher framework....

[preardon]

You definitely could argue that, but if you've got the bulk of your logic inside your domain (entities) then what your handlers should be doing is fairly light 😊