First Indicators of Overengineering in Your Project

1. You start to use terms like "potentially", "in future" or "scalable".
2. You spend more time thinking of  "encapsulation", "abstraction" and "decoupling", than the actual problem.
3. You believe, that the with amount of frameworks, libraries, and languages (better polyglot projects), the qualitity of the software will improve.
4. You are able to replace every single concept, class and layer - but this feature actually cannot be derived from the client's requirements.
5. Just looking at the code - you do not understand what happens - you need addtional tools, products and consultants :-) to understand it.
6. You hate monolithic structures - so everything is configurable, replacable - of course at runtime. If it becomes too complex, go to point 5.
   
7. You start to implement a generator to tackle the complexity.
   
8. Your configuration file is getting slightly bigger, than your code.
9. Your interface is so fluent, that only domain experts understand the code :-)

The problem with patterns, best practices and idioms is the overuse of a single principle. Regardless what you are considering: overuse of DRY can lead to "fat" layers and classes, overuse of  Separation Of Concerns to many fine grained units, overuse of modularization to jar, plugin or just governance hell. Common sense and the balance between concepts and idioms are the solution- but it's hard to find in real world :-).

[I expanded the thoughts above in the book "Real World Java EE Patterns"]