Actor Framework Documents
Note: I don't consider myself and AF expert but found myself documenting what I feel was a successful approach to system "controller" logic using AF and decided to post here. Not a ton of detail but I'm happy to expand and may keep poking at this over time. Please do comment and push-back on my approach - we are all still learning!
In my line of work, we make physical integrated systems (although I submit that many of the same design principles and the solution described below have utility outside the physical world).
As good engineers in ME, EE, and SE we try to use modular design and common components. In the software world this has led to the adoption of flexible design patterns including the Actor Framework. One approach that has proven to work well I have dubbed the “System Flower”. This is not truly new, just perhaps more artistically described for my enjoyment here 
The system flower is a classic OOP pattern with device abstraction. Here the only twist is the implementation in AF where the Actor class is the ground on which a common “System Item” class stems. A central “Controller” inherits from System Item as well as all the generic device (or any other system item) classes. Generic devices fold out into specific implementation. Although not required, this pattern lends itself to be defined at run-time by evaluating available devices and configuration definitions.
The benefits are many: reasonable abstraction, common methods for things like configuration and persistent/state data management. One arguable downside is the use of a central controller which itself is not all that flexible as it must be able to appropriately handle all the generic device/item classes.
Actor messages are established between the controller and the devices/items. Special note: I have found that there is often a need for one leaf/petal actor to know the state of some data derived from or managed by another (i.e. “what is the current voltage on power supply 0”). Instead of some complicated upstream and downstream return messaging structures or, worse, breaking normal AF caller-callee message scope, I use Functional Globals or Action Engines and simply need to be careful about who writes to the data.
Cheers,
-Jolt
Is there an example of this flower structure posted somewhere? I'd appreciate seeing this in action.
