Report AOP architecture issues and options in Application Design & Architecture Posted August 15, 2014 Your Actor A has a base "Do" implementation which gets called on any message being received, right? The only thing adding B as a dependency is the message set up to do this (and it's associated dynamic dispatch "Do"). I was the opinion this would make Actor B a dependency on the specific message for launching B and NOT of the actual Actor A. Or do you somehow have the messages stored within A? You are correct, but in most AF systems, the message simply calls a method in the Actor where the real work is done. So, the code that launches B would be in A. But that does not mean you could not put the code in the message 'Do' only and isolate B from A. But then you need to ask how is the message being called? In most cases, A is calling itself to create B due to some state change or other action. In that case, some method in A need to send the message to itself and then A has a static link to the message which has a static link to B. This is exactly what happened to me and took a while to understand what what happening since there is no way to visualize this. How about making Actor B an interface and use the factory pattern? If Actor B were an interface it would not have any dependencies to Actor C, since that would imply implementation. Now if you test Actor A in isolation it would in fact load the interface of Actor B into memory (cannot be avoided due to a static dependency), but the actual implementation of Actor B (that causes more dependencies to load) is not necessary. I have little experience with AF, but in my opinion using interfaces and the factory pattern should drastically reduce the number of classes in your project (you would "only" need the interfaces and all Message classes which belong to them). The actual implementation can be done seperately. Wouldn't this result in even more classes? I would need the abstract interface class and then concrete class for every actor? Or am I misunderstanding you?