Cuando se diseña una aplicación no hay estándar manera de estructurar en paquetes, la experiencia es lo que generalmente ayuda a cada uno a decidir cuáles son los nombres apropiados para nuestros paquetes.
Acerca de las implementaciones de empaquetado de sus interfaces en el mismo paquete o en otro diferente, solo piense cómo está estructurado Java: generalmente una clase de implementación está empaquetada en el mismo paquete que su interfaz, pero no todas las veces.
Si estaba a punto de tener varias implementaciones de los mismos DAO, tendría sentido tenerlos estructurados en los paquetes secundarios .jdbc, .jpa o .jdo. Si solo va a tener una implementación, las dos opciones que enumera tienen algún sentido (el mismo paquete o un subpaquete .impl).
En cuanto a la sobreingeniería, le recomendaría este article. Aunque solo tendrá una implementación de sus DAO, tendría sentido definirlos como una interfaz e implementación, ya que eso le ayudará en un futuro potencial a reescribir sus DAO para otros marcos, mientras que el código que hace uso de ellos se mantienen sin cambios.
Al final, depende de usted (o de usted y de sus pares) llegar a un consenso y tomar la decisión que tenga más sentido en su caso específico.
EDITAR
Una aplicación normalmente tiene una implementación por interfaz DAO y que no es el exceso de ingeniería en absoluto, simplemente no tiene sentido tener la misma interfaz DAO implementado por la APP y de JDO . Algunos de los propósitos del uso de la interfaz/patrón de implementación es facilitar la refaccionamiento, la prueba mediante objetos simulados, etc.
PD: generalmente confío en JDepend para distribuir mis clases de aplicación en paquetes evitando ciclos como la mayoría como puedo.
¿No hay implementaciones alternativas en absoluto? ¿Ni siquiera la prueba unitaria se burla? –