How is the actor model used

I generally try and describe Object-Orientated-Programming by using real world examples.

For example, I might say that a class called Vehicle describes the minimum things that a vehicle is. I'll ask the person to tell me what he or she thinks a vehicle is. Sometimes they say things like "Well, like a car or a truck", and I'll nod and agree with them. Then I'll ask what the differences are between a car and a truck. Sometimes they mention size, sometimes the purpose, and other things.

Then I'll ask them to forget about a car, or a truck and just ask them to continue to describe a vehicle:

"Oh, well it moves"

"It has an operator, or a driver"

etc...

Soon, we know what a Vehicle is and I said that in OOP we would define a vehicle, and for the sake of argument say it can move, and give it a driver of sorts. Then I'll ask, ok, so what does a Car have?

"Doors"

"Windows"

And then a truck....

"Doors" "windows" "More Wheels!"

Soon, after lots of discussion, the other person generally has identified:

1) What constitutes a vehicle

2) What constitutes a car

3) What constitutes a truck

4) What constitutes an aeroplane.

All without any technicalities. We've divided up the properties of each in to the right areas. They understand inheritance ("Yeah, a car is a vehicle, a truck is a vehicle, but a car is not a truck, it's SIMPLE, duh!").

They even understand polymorphism, "Sure, they basically do the same, but that might do it slightly different.". We can talk about behavior and where that should live in our tree of objects.

Depending on their education and background, some get it faster than others. But when I compare OOP to real-life objects, most people always get it. In fact, I have found in conversations with non-technical people things I had never thought of. Vehicles don't have to be manned, for example (drones), but would a programmer have thought of the operator of the vehicle as a property of it? I am not saying it is right or wrong to have an operator mentioned, but it causes us to think about what we are modelling and what we are trying to achieve when we develop software.

Now, partial template specialization, on the other hand.... :)

I think, your question is not specific to Akka.NET exclusively. So I'll answer it being Akka/Scala developer.

0 Not everything is an actor. Functions are still functions with all that functional composition and purity.

1. Actor model becomes very useful when you extend beyond CRUD in the land of Domain-Driven-Design and Hexagonal Architecture.
2. I can't tell for .NET, but in the JVM world most database calls (JDBC) are blocking. Meanwhile, actor system usually works on a limited thread pool compared in size to the number of your CPU cores. So, if your actor system works with blocking calls, Akka allows to configure separate thread pool for that subsystem, i.e. subtree of the actor system's supervision tree. So you can leave your nonblocking business core with 4 threads and give 200 threads to storage subsystem.
3. Immutable (Persistent, Functional) data structures are the key. You don't need synchronisation to use them. Though sometimes you may need to pass a reference to e.g. ByteStream. Well, you should check that sender doesn't try to work with the instance after it had been sent.

In general, what is the main difference between Erlang and Akka implementations? In Erlang each actor has its own heap and garbage collector. Hence, no shared mutable state, no stop-the-world gc. This gives us soft realtime qualities. But you pay on copying data from actor to actor. In JVM (and .NET?) heap and gc are shared. You don't have overhead like in Erlang, but you should be disciplined not to shoot yourself in your own foot.

Now a couple of use cases I myself have encountered. You know RabbitMQ: exchanges, queues, bindings... If connection fails - some drivers can automatically redeclare them all. I've implemented this logic with Akka, because the driver didn't suit my needs. It was first hard to figure out that logic, but after a managed to separate, what was ephemeral, and what should persist failure - things clicked. The former went to worker actors, while the letter resided in actor's props (which is effectively an actor instance config) and supervisors. This is what is meant when you hear of actor resiliency and self-healing. It is not out-of-the-box, but actors help greatly to implement this logic as straightforward as possible, right after you figure it out yourself.

Hexagonal architecture and concurrency. I've implemented CAS 3.0 Protocol Specification for internal needs using Akka.

First of all, business core, http server, http client, db interaction - all were separated in different actor subsystems and had clear interaction surface. You can test them separately. Business core doesn't know, what an http protocol is. It just known how to handle business commands. It doesn't know anything about db including interfaces. It just knows what messages to send and what to receive. And db's ActorRef, of course.

Second, in CAS protocol there are quite a few things that you need to check for a single user request. So, I implemented every check in a separate worker actors. They are configured with necessary ActorRef-s and a timeout. Either they finish processing before timeout and commit suicide, or the timeout is reached, and the produce error response and, again, commit suicide. Meanwhile, there are other actors, which I called services. They act as supervisors for mentioned workers and existed as long as the whole runtime. Their ActorRef-s are static addresses, which you can use to configure different runtime components during application startup.

Hope this helps