3
votes

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)

1

1 Answers

1
votes

Service Fabric is definitely designed for that kind of scenario. You will need to be clever about partitioning your state so that a large number of actors can be accommodated - you have to think about the potential size of the data, the number of actors and the size of your nodes.

What Service Fabric doesn’t support (yet?) is a way to automatically re-partition your services. So if you start with 3 partitions and at some point you realise you need more, you’ll need to handle that yourself. You'll need to do some experimenting to see how many partitions you need but in general it’s recommended that you start with a large number.

Worth reading this https://azure.microsoft.com/en-gb/documentation/articles/service-fabric-concepts-partitioning/ and having a look at the comments.