Thinking in Actors – Challenging your software modelling to be simpler
jeremycarterau.substack.com
Thinking in Actors – Challenging your software modelling to be simpler
1–10 of 48 posts
Re: Thinking in Actors – Challenging your software modelling to be simpler
#2Huge fan of building systems on top of Orleans Actors (one of the tools discussed in the article)
Re: Thinking in Actors – Challenging your software modelling to be simpler
#3Does anyone care to share an example of the OrderService that is not anemic?
Re: Thinking in Actors – Challenging your software modelling to be simpler
#4Does anyone care to share an example of the OrderService that is not anemic?
It's tricky to provide a really good example right now. I notice in the .NET world there are like these DDD "starter packs", and my god, they're just layers of maintainability hell. If you look at older OOP/DDD books you'll notice that the domain object has real world methods on it, just like as if it were from a UML diagram.
What you should end up with are plain OOPy objects that mirror the real world. They're not skewed or constrained by their database model. They shouldn't have any dependencies on your infrastructure layer. The object should encapsulate state, behaviour, validity and consistency.
An example (which is probably overkill) would be https://learn.microsoft.com/en-us/dotnet/architecture/micros...
The next post is about modelling an actor and it might provide more insight for you.
Re: Thinking in Actors – Challenging your software modelling to be simpler
#5The article seems to be smashing together two (seemingly) unrelated topics and doesn't offer much in the way of a solution. What alternative design does the author propose? Is it possible to solve the problem with traditional object-oriented design techniques? It's not clear that the issues presented require or substantially benefit from the actor model without seeing a best in-class OO example.
Re: Thinking in Actors – Challenging your software modelling to be simpler
#6Does anyone care to share an example of the OrderService that is not anemic?
It's tricky to provide a really good example right now. I notice in the .NET world there are like these DDD "starter packs", and my god, they're just layers of maintainability hell. If you look at older OOP/DDD books you'll notice that the domain object has real world methods on it, just like as if it were from a UML diagram. What you should end up with are plain OOPy objects that mirror the real world. They're not s…
It's not clear from the article whether actors offer significant benefits (or disadvantages) for data modeling versus the traditional OO paradigm. The article reads more like an introduction that describes the problem and teases a solution rather a complete article that offers a solution and evaluation of it.
Re: Thinking in Actors – Challenging your software modelling to be simpler
#7The article seems to be smashing together two (seemingly) unrelated topics and doesn't offer much in the way of a solution. What alternative design does the author propose? Is it possible to solve the problem with traditional object-oriented design techniques? It's not clear that the issues presented require or substantially benefit from the actor model without seeing a best in-class OO example.
As I mentioned there's nothing novel in this post, especially for a senior. This is more about getting some context out of the way so that I can show some techniques in a future post.
Re: Thinking in Actors – Challenging your software modelling to be simpler
#8Earlier quoted context omitted.
It's tricky to provide a really good example right now. I notice in the .NET world there are like these DDD "starter packs", and my god, they're just layers of maintainability hell. If you look at older OOP/DDD books you'll notice that the domain object has real world methods on it, just like as if it were from a UML diagram. What you should end up with are plain OOPy objects that mirror the real world. They're not s…
It's not clear from the article whether actors offer significant benefits (or disadvantages) for data modeling versus the traditional OO paradigm. The article reads more like an introduction that describes the problem and teases a solution rather a complete article that offers a solution and evaluation of it.
That's fair feedback. I wanted to post it in 3 parts, but I see now I probably should have just made one large post.
Re: Thinking in Actors – Challenging your software modelling to be simpler
#9I suspect that a lot of what can be done with actors can be done in Go using the "Don't communicate by sharing memory, share memory by communicating". Basically a consumer of a channel can act like an actor. What we don't get for free is the activation and resiliency. A closer one would be Erlang/Elixir on the BEAM. On the more advanced end would be using F# or Pony.
Curious to see what the follow-up parts will post. I am interested in actor model programming and want to see different ways of understanding and using them.
Re: Thinking in Actors – Challenging your software modelling to be simpler
#10Earlier quoted context omitted.
It's not clear from the article whether actors offer significant benefits (or disadvantages) for data modeling versus the traditional OO paradigm. The article reads more like an introduction that describes the problem and teases a solution rather a complete article that offers a solution and evaluation of it.
That's fair feedback. I wanted to post it in 3 parts, but I see now I probably should have just made one large post.
You could always post the 3 parts simultaneously, so anyone who wants to dig deeper can continue into the series.