...
- here the supporting methods would simply read from the fields of the mixin that represent the parameters of the mixin itself.
- the domain event class is still separate
Mixin and Parameters and Domain Event combined (proposed - but a step too far?)
A further possible unification is to make the mixin also act as the domain event. I am not sure this is a good idea... my mental model is that the mixin acts as the "command", representing an intention to perform something, where as the event is a record of a fact that occurred. But maybe this is too theoretical, and actually it would make sense to combine the, If so, it would look something like:
| Code Block | ||
|---|---|---|
| ||
@Action
public class Customer_placeOrder extends ActionDomainEvent<Customer> { // ??? this looks very odd
private final Customer target; // target
...
@Parameter() @MemberOrder(1) // supporting methods support
Product product;
@Parameter() @MemberOrder(2)
int quantity;
@Action(domainEvent = Customer_placeOrder.class) // ??? I wonder if this is valid syntactically
public Customer act() { ... } // execution ??? these methods would be available to the subscriber
public boolean hideAct() { ... } // supporting methods ??? these methods would be available to the subscriber
public String disableAct() { ... }
public String disable1Act() { ... }
public Collection<Product> choices0Act() { ... }
public Product default0Act() { ... }
public int default1Act() { ... }
public String validate1Act() { ... }
public String validateAct() { ... }
} |