text: May 05 2015 05:53
  Ok, here's my question: How should an actor and its logic be related? Especially an actor representing the UI. Here's how the bootcamp does it: https://www.lucidchart.com/publicSegments/view/55485914-8804-4606-b2d2-56140a004a17/image.png The form uses/creates the actor. (And the actor even uses (parts of) the form.) This doesn't feel right. That way the actor does not encapsulate the UI. So how about this: https://www.lucidchart.com/publicSegments/view/554858f1-80dc-4005-b197-081e0a008539/image.png ? Here actor knows the form, but the form is oblivious to the actor. This to me is real encapsulation of the "UI detail". https://www.lucidchart.com/publicSegments/view/55485900-8b14-46c7-b9b3-5d590a00ce79/image.png What do you think? Am I missing sth?
  May 05 2015 06:22
  IMO it would be risky to let an actor own the form. Actors are not designed to be durable - in case of any failure they should be easy to destroy and recreate. Think about what's done with the form in this scenario
  May 05 2015 06:37
  Don't let things that have their own lifecycle be owned by actors, as actors can restart. it would be strange if the actors pulls down the form and then displays a new one.
  May 05 2015 06:40
  But then: There would be no logic in the actor. It's just a capsule around the form. There's no risk, there is no distribution. If I can't trust a local actor with hardly anything in it to run smoothly, what can I trust? The Frontend Actor's sole purpose is to sync data to the UI thread. That's all.
  May 05 2015 06:41
  but what that gives you?
  you can trust it to deliver updates to an existing form?
  May 05 2015 06:42
  Why wouldn't I trust the Frontend Actor to relay an incoming message to the form?
  thats what I said, you can trust it to do that, but as the form has its own lifecycle, you cant let the actor own the form
  May 05 2015 06:43
  @Horusiath: it gives me encapsulation. On a high level of abstraction I don't have to think about the UI. It's not visible in the design.
  as the actor might crash and burn and get restarted.. you dont want the form to be disposed and closed just because the actor dies
  May 05 2015 06:45
  The form is constructed outside the Frontend Actor (as in my sample code). It's injected into the actor.
  ehh, I think we misunderstood each other :)
  I think @rogeralsing and I were talking about scenario, when actor instantiates a form ;)
  May 05 2015 06:47
  Oh, no, it's gonna be injected.
  Of course. But conceptually the form is encapsulated by the actor.
  In my view, actors don't contain (domain) logic themselves. They are just hosts for it to enable concurrent processing.
  That's why there is a Domain Logic shape in my above drawings.
  May 05 2015 06:52
  Concurrency is orthogonal to domain logic. It's a non-functional requirement that should be represented by a different module (according to SRP).
  May 05 2015 06:53
  actors which use UI thread shouldn't focus on anything else than UI updates. I think that your idea is good
  May 05 2015 10:50
  How is an aggregate operation is done in AKKA.NET? For example, in an e-commerce system, I want to find how many orders are in the product category 'computers' and what is the profit ((sale price - cost) * number of orders)? Should I create a separate actor like 'OrderAggregateForACategoryActor' to do the aggregation? Or should I use the original 'OrderActor' and it should have the message handling.
  May 05 2015 10:55
  thats a very broad question. do you keep all orders in memory, if so, why?, how are they they structured?
  May 05 2015 10:57
  @varghesep: To me the first question to ask would be: How would u do it w/o actors? How would you distribute functionality across classes?
  but in general when doing aggregation, you fan out, eg. if you have two actors,"usa" and "europe", and unde reurope you have child actors with "sweden","norway","france" etc. and under those, you have your orders. (for example.) then you could create an aggregator actor that waits for responses , and then pass a message to usa and europe, that then in turn forwards the message to all their children, and then forward from each country to each order owned by that country
  and then let each leaf node report back whatever result you want to the aggregator actor
  but when talking e-commerce, very few systems would need to keep each order that have ever existed as an actor in mem. but sure, if you do stock trading or something that cannot afford roundtripping a database then it might be a good idea