I am getting more into understanding Domain Driven Design and a bit confused about how Naked Objects Pattern and Onion Architecture could relate to each other?
Individually how they relate to DDD is quite clear, but is it also possible to relate them with each other?
(Declaration of interest: I was the author of the Naked Objects architectural pattern, and manage the Naked Objects Framework - NOF.)
I do not profess to know the Onion architecture well, but at one level the ideas seem compatible with Naked Objects; at another level it is comparing apples to oranges.
The Onion Architecture is a set of design principles that you could apply when building an architecture from scratch using various technologies and patterns. In theory, so is Naked Objects; in practice you would only adopt the Naked Objects pattern by building your systems using a framework that implemented it - it is too much like hard work to write your own. The Naked Objects Framework is the largest, and purest, such framework, but not the only one.
So the meaningful comparison is not between the Onion principles and the NO principles, but between the former and a specific implementation of the NO principles. I'll, obviously, use the NOF as the example.
NOF very strongly implements and enforces the principles that Onion is derived from: very strong separation of concerns. The domain model is almost completely independent of the infrastructure: the sole point of contact is via a single, very lightweight, interface (IDomainObjectContainer), which defines a service, an implementation of which is automatically injected into any domain entity or service that wants it.
Even more strongly than the Onion architecture, your UI has zero dependency on the domain model - because it is generic. (Unless you start to customise the UI, in which case you risk losing the benefits of the NO pattern).
The principles of Onion could be further applied within the domain model - ensuring that all domain services, for example, are defined and used by interfaces only. I have seen some people try to have all interactions between domain objects pass through interfaces only, but I have never seen this be made to work at any scale and see little value in it. You might like to read up on the 'Cluster' pattern, which is a pattern for breaking up a very large complex domain model into independent clusters with a strict hierarchy of dependency. This pattern is not dependent upon NO, though in practice there would be little point in adopting it if you didn't also have the benefit of NO.
And here I come to my main point, and what led to the definition of the NO pattern in the first place. It is all very well adopting strict principles for separation of concerns across the architecture. But unless you can get to the point where both the persistence layer and the presentation layer are 100% derived, automatically, from the domain object model, you end up losing much of the advantage of that separation of concerns, because any change to the domain model implies changes to the other layers, indirectly if not directly. Modern ORMs have done a great job of the domain model to persistence layer mapping; Naked Objects did it for the domain model to UI layer.
In short, if you adopt a framework firmly committed to the NO principles, you will get the claimed benefits of Onion. If your desire or need is to build your own architecture and you want to adopt the Onion principles then that's fine, but it is not then worth trying to figure out how to somehow retrofit any of the NO principles to that custom architecture: it will be very hard, and you probably won't see any of the benefits.