From my experience, if I focus on the domain, and play around with it for a while, I will start to see a structure behind it (different from a relational structure). And, I've found that if I structure it correctly, the aggregates sort of just fall out.
I agree with you to be wary of book authors' ideas. However, the paradigm that Eric Evans documented was truly useful to me. But, I also think that the book he wrote on the topic was a hard trod, overly abstract, and didn't make much sense at first. I mean, it sort of made sense in theory. But, it wasn't until I tried it out on particular projects that I saw its usefulness.
I wouldn't recommend trying it out on a brand new project. But, instead, take an existing project, fork it, and try to apply it. At least you'll get a better understanding if it can and will work for you, or not.
DDD helps me to not go insane. But, on the other hand, I've had to listen to quite a few complaints from my team, who usually want to see something more procedural.
Aggregates (and drawing their boundaries), especially when combined with domain models backed by an ORM must be one the more impractical programming concepts that I've met in my life.
P.S. I also don't trust programmers who write (enterprise) books for a living.