Can Orleankka integrate with this architecture?

[JbmOnGitHub]

First of all, thank you for this great project!! I learned a lot of things.

I try to integrate cqrs & eventsourcing into my architecture and I try to find out if orleankka could match.

The need would be that Orleankka is the "message transmitter" (as shown below) that depends on my domain but not the other way around.

Q1 : The videos pointed in the readme of the project make me think that it is possible with Orleans so it should be the same with Orleankaa?

Q2 : I have look at the issue "help wanted" for an example of Http-endpoint with WebApi (C#). Do you agree that this WebApi should expose "public commands" and perform different tasks before translating them into "domain commands"? (as shown below)

[aprooks]

In short, yes it can.

Though I don't see why this message transmitter is stateful and why it should benefit from Orleans'es architecture

[aprooks]

Q1. Orleankka is an interface facade on top of Orleans, so anything you can do with Orleans should be possible with Orleankka and vice versa. Each interfaces having their own pros/cons

[aprooks]

Q2. I would not call "adit, authorisation and validations" as a command modification/translation. You can always add this layer transparently. E.g. when you send a serialized domain command from UI you can add metadata as headers. Check this meta without modifying command itself and the relay to domain level without "modification". Also, validation rules can be either published as a contract and shared with API or even UI via Swagger notion or something else.

Some people prefer to expose REST like api and then transform these calls to domain commands. For example, something like PUT /user/10/password would be translated to UpdatePassword command.

So it's more of a question to how you design your api and to which layers you want to expose your domain messages. I personally, prefer to treat domain commands as public across whole app, including UI, thus I have less work to maintain "translations"

[JbmOnGitHub]

Though I don't see why this message transmitter is stateful and why it should benefit from Orleans'es architecture

@aprooks : you're right. "Message transmitter" does not correctly transcribe my need for Orleans here. Maybe i need to change "Message transmitter" with "middle tiers for distributed high-scale apps" ?

[yevhen]

@JbmOnGitHub +1 to @aprooks Orleankka can be used in this architecture easily. If you want domain independence you can just use Orleankka actor as a host for the domain Aggregate and then simply transmit your command to it. Such design will give a performance boost to your app by saving on unnecessary reads (actors will be keeping you aggregates in memory and will make all operations on them thread-safe).

[yevhen]

Just don't inherit your messages from ActorMessage to be free from infrastructure (Orleankka) dependency. Also, you may still be dependent on ActorMessage and other Orleankka concepts but have your domain to be free of it by unpacking message data into an object call, like this:

class InventoryItemActor : DispatchActorGrain, IInventoryItemActor
{
      InventoryItem item;  // this is a domain aggregate you will load upon Activate

      // unpack message on wire at the boundary, all domain logic is kept inside aggregate
      IEnumerable<Event> Handle(CheckIn cmd) => item.CheckIn(cmd.Quantity);     
}

[aprooks]

So this way Orleans becomes also a cluster hosting solution.

[JbmOnGitHub]

@yevhen, @aprooks : Thank you for your advice, it perfectly matches what I was looking for!

[JbmOnGitHub]

My sequence diagram updated where :

• Orleankka is a cluster hosting solution
• Domain commands as public across whole app (as mentioned by @aprooks)

[aprooks]

Looks good. You don't need ack/nack as calls are blocking by default.