Plans to deprecate apply_* handlers in AggregateRoot?

[dvrensk]

Hello all, happy Thursday and happy summer to those of you in the northern hemisphere!

The documentation on Event Sourcing with AggregateRoot talks about the two ways of defining handler methods and notes (only by dropping the word “(deprecated)” in the heading) that the def apply_* approach is deprecated. There is nothing in the code to indicate that it’s deprecated, no notices, no comments, and I haven’t been able to find anything that mentions a rationale or a timeline. Does anybody have any details or pointers for me to find out more?

The reason I’m asking is that I hope that it's not a real deprecation and I hope to get this confirmed. I can see the point of the on handlers, but the apply_* methods actually allow me to do proper TDD without side effects, which I’m very much in favour of.

[mostlyobvious]

Hello!

We plan to get rid of apply_ methods approach in aggregate_root in RES 3.0 release (next major release introducing breaking changes). The timeline is not set in stone and we'll definitely add deprecation notices to last releases in RES 2.x line. The documentation went ahead since it is probably the first place people may learn about apply_ method handlers.

The PR removing it is here and there's also provisional list of expected changes in next major release. It has been sitting there for a while — no one likes introducing breaking changes frequently.

Despite future removal from aggregate_root you could still continue using this approach. It is a matter of providing desired apply strategy. I encourage you to make an in-project strategy or aggregate root module wrapper that would insulate the code from future RES changes. Without on handlers it would be even simpler:

# desired strategy to call handlers for applied events
class MyStrategy
  def call(aggregate, event)
    aggregate.method(apply_handler_name(event.event_type)).call(event)
  end
 
  private

  def apply_handler_name(event_type)
     "apply_#{to_snake_case(last_namespace_part_of(event_type))}"
  end

  def last_namespace_part_of(event_type)
     event_type.split(/::|\./).last
  end

  def to_snake_case(string)
     # ...
  end
end

# passing desired strategy to included AggregateRoot module 
class SomeAggregate
  include AggregateRoot.with_strategy(lambda { MyStrategy.new })
end

# or via custom module to hide the plumbing
module MyAggregateRoot 
  def self.included(base)
    base.include AggregateRoot.with_strategy(lambda { MyStrategy.new })
  end
end

class SomeAggregate
   include MyAggregateRoot
end

but the apply_* methods actually allow me to do proper TDD without side effects, which I’m very much in favour of

Can you please give me an example of that? Do you perhaps mean asserting on apply_ methods being called with expected arguments?

[dvrensk]

Thanks for your elaborate answer! As for my needs, yes, asserting on apply_ being called is one example, and another (oversimplified and partly non-idiomatic) would be

agg = ToDoTask.new(uuid)
agg.apply_to_do_task_created(created_event) # I want to do this
agg.apply_to_do_task_resolved(resolved_event) # and this

expect(agg).not_to receive(:apply_to_do_task_resolved) # This is not really the point, just a nice-to-have
expect { agg.resolve }.to raise_error(InvalidState)

Using our own apply strategy feels like a sufficient solution to me, but I expect some team members to say that we should use as little configuration as possible and strive for making public documentation stay relevant to us (which is a point that has been raised before and is not without merit).

Thanks again!

[mostlyobvious]

Thank you for the example illustrating your use case!

When using events to load aggregate state in test I'd prefer agg.apply(created_event) to agg.apply_to_do_task_created(created_event). The apply is already part of public interface and it hides internals (apply_* handler methods, on handlers or whatever strategy you have there). This is how repository interacts with aggregate instance.

I'd also prefer calling aggregate methods to reach desired state to using events for the same purpose. Calling aggregate methods would have the benefit of checking aggregate invariants and making sure you don't recreate impossible state. More or less something like that (with rspec):

specify "product supplied" do
  # arrange
  product.register(store_id: 1, sku: "BOOK") 
  
  # act
  events = product.supply(30) 
  
  # assert
  expect(events).to match([ 
    an_event(ProductSupplied).with_data(
      store_id: 1,
      sku: "BOOK",
      quantity: 30)])
end

Here's a short excerpt from Domain-Driven Rails on the topic of testing Aggregate Root: https://cryptpad.fr/file/#/2/file/GVpckU7T-0KhyKva8tS18cUj/

[dvrensk]

Thanks for the follow-up! I prefer not to run more than one command on a given aggregate since that's not how they are used for real (in our code base). We have command objects with validation and an execute method. execute creates a new aggregate, fetches the event stream and applies all existing events before applying the command. It is never the case that one aggregate receives two commands. Thus doing that in testing would make it easy to build something that doesn't work in the bigger system, for instance by (inadvertently or through ignorance) putting some of the state-changing code in the command handler.

Another reason to prefer applying events is that when commands evolve over time I only need to handle the ones I create now, but I need to be able to handle events that were generated years ago, even if creating those events or those series of events wouldn't be possible today.

Anyway, I really appreciate how you shine an explanatory light on this construct from many different angles!

[mostlyobvious]

Btw. there's a repository of different aggregate implementation beyond AggregateRoot at https://github.com/arkency/aggregates