You are right that there is a danger in the fact that the object being passed into the AOP advices can be changed.
Usually, I'm avoiding this kind of situations. It can be terrible to debug.
In our teams, we have a rule that the calls to Before/After/Around can only happen in the Glue code.
Obviously, we also make sure that everyone involved is familiar with AOP and knows what is the architecture.
As for the use cases for AOP, I know it's not a common practice to use it. Orthogonal concerns are the best fits, but not the only ones.
There was an interesting research project at IBM, called Hyper/J. It was a little bit of inspiration for the AOP usage in the hexagonal.js architecture.
Here is a good paper on Hyper/J (and the idea of Multi-Dimensional Separation of Concerns)
Usually, I'm avoiding this kind of situations. It can be terrible to debug.
In our teams, we have a rule that the calls to Before/After/Around can only happen in the Glue code.
Obviously, we also make sure that everyone involved is familiar with AOP and knows what is the architecture.
As for the use cases for AOP, I know it's not a common practice to use it. Orthogonal concerns are the best fits, but not the only ones.
There was an interesting research project at IBM, called Hyper/J. It was a little bit of inspiration for the AOP usage in the hexagonal.js architecture.
Here is a good paper on Hyper/J (and the idea of Multi-Dimensional Separation of Concerns)
http://helios.mm.di.uoa.gr/~anya/pms521_papers/p734-ossher.p...
Thanks for your comment, it was very valuable.