When to use an isolated aggregate in an action?

When to use an isolated aggregate in an action?

  

Hi,

Best practices suggest to "...never create an action to execute an Aggregate". However it also goes on to remark that "...this invalidates code reusability."

I have a repeating aggregate in various preparations and screen actions that GetsCustomerById.
The Customer entity exists in a shared (library) espace database and contains 19 attributes. In many of the usages only a view fields are used, but the data size of the entity record is not particularly big. Except for Name, Surname and Fullnames, all the other attributes are either long integer or lookup IDs to other entities.

Is this a case where it should exist in a re-used action instead of being repeatedly used in a aggregate?

In my mind a public action in the same common espace containing the Customer entity, would make the most 'structural' sense here.

Thanks

Al



Solution

Hi Albert,

Personally, I would keep using separate aggregates instead of creating a public action. I hate the idea of getting all 19 attributes from the database and then using just one or two of them. Also, there isn't much logic involved in simply getting records from the database. So dragging an aggregate to get them is basically the same amount of work as dragging your public action. I think it would only make sense to create the action if you needed to perform some additional logic during the fetch, like validating user permissions or pre-processing the aggregate's result.

Solution

Hi Albert,

For your particular example, typically you'd receive the CustomerId as an Input Parameter of your screen, right? I don't think reusability is particularly relevant when the Aggregate can be automatically generated by just dragging and dropping the CustomerId in an Action flow with no further modification, it's not like you can make mistakes there.

Even if you did consider it makes sense to reuse and can live with the overhead of fetching the entire record, I'd suggest using directly the GetCustomer Entity Action of the Customer Entity (available even when the Entity is shared read-only), no need to reimplement its functionality.

Edit: The only scenario where it would make sense for me to have your own implementation is, like Aurélio mentions, if you consider you may want to add additional logic like security constraints or consistently manipulating the Aggregate's result after fetching it. But that's no longer a reusability concern.

Hope this helps.

Thank you Aurelio and Jorge, that cleared things up. 

:-)