Vaughn Vernon describes using Actors as DDD aggregates here: Vaughn Vernon on the Actor Model and Domain-Driven Design
Consider an Invoice aggregate: Is the life cycle of the Azure Service Fabric Actor to be used such that 1 Actor can be used to hold the state of only 1 Invoice (say with identity "ABC") and the reliable storage represents the state of that Invoice. Or is some kind of Flyweight implementation necessary to pick an available Actor instance and load the state for Invoice "ABC" for the duration of the call ?
The first option appears to fit with the idea of an Actor but that means the Fabric infrastructure needs to have been designed with this in mind with 1 Actor for every Invoice in the System (an unbounded and undoubtedly very large number)