My opinion is it's true that aspect-oriented programming has the drawback of hiding a lot of details in the main flow of the domain (or any other layer)
IMO, this is the central problem of using such AOP approaches in DDD - it hides details. Now, for strictly technical domains, such as logging, this is often desirable. AOP works well for such domains because it is, in a sense, a characteristic of a technical domain itself - an extension to traditional OOP composition. DDD on the other hand targets non-technical domains - business use cases. As such, one of the goals of DDD is the distillation of domain knowledge freeing it from technical concerns as much as possible. A step toward achieving with OOP is clustering data and behavior together inside objects. Another step is moving away from technical names for behaviors to more business specific names for behaviors. This allows you to capture the surrounding business context associated with behaviors, not just the technical context.
What would be helpful for DDD is a new set of abstractions. Not a needless layer of complexity, but something that creates new semantics. As Dijkstra stated, abstractions should create new semantic levels. This can come in the form of a DSL that allows expression of domain knowledge agnostic of technical concerns. The application would then attach this DSL expressed domain to infrastructure - persistence, UI, services, etc. Creating such DSL that is both expressive and readily "attachable" is a big challenge.
To answer your question, yes your object model is itself anemic even though it is composed with richer behaviors through aspects. However, this only addresses your object model and whether an object model is anemic or not is only part of the puzzle - the object model is a tactical pattern not a strategic one.
Your goal seems to be headed in the right direction - you wish to elevate the level of abstraction beyond facilities provided by OOP alone. I just think that the drawbacks of AOP outweigh the benefits in the DDD case.