Things like aspect orientation and separating of concerns are really trivial for me. I mean I develop software and I write an aspect when I see there is a need for that. I use it pragmatically, and the number of my custom aspects is increasing every few days last weeks.

But as we see not for all people that's the case. I will try to tell how it looks from my position. And I must start from the beginning: the client of application.

To familiarize with a business domain is the first and most important thing.
It is your client who drives the application, so the first thing is to dive into the client's business and to look what's there. But, just don't spend too much time there.
Practical way (agile?) says: it would be nice for you client to see the first version of application very soon. So I implement the domain - simple Java classes and methods and plain JUnit tests.
And in the first week of development I'm only worried about implementing first business task of my client. I don't think about persistence (you use Prevayler for prototyping, don't you?) or any other system "services" - it is not important right now. Client is important, and time is important.

And it happened, when I worked this way, I've started to see things differently. Some years ago I tried to design a whole system at once. It is impractical. Requirements will change, client will wait. It just doesn't work.
So I try to think only about functionality of the core system and nothing more. The rest of the system are system's services - non functional requirements like authorization or tracing support - they will come at a later stage, when need arises. Then I will take care of those services - by implementing an aspect of course.
Like Andrzej Krzywda assumes: one can practically add any orthogonal functionality to an application at any given moment of time. And that is true. It worked out for me with authorization and the rest of my aspects.

Persistence strategy as I believe was the strongest point in my developer's history. When you choose simple persistence, then you don't have problems others do. This is the right direction: to get rid of problems. And "simple" doesn't mean primitive. It is the art to make complex things look simple. I found when code looks clean, many things become brighter. And it is persistence that makes your code look uglier at most of the time. But I don't want to talk about this topic right now - have a look on PAT, and you'll see my way..

Need the examples of the code I create? PAT provides a Forum demo ready to extends to you super-duper, enterprise solution...