Improving design for a CustomerDAO with DatabaseManager object
Single responsibility principle

In terms of SRP, the current code is good, each class is has one clear purpose:


Customer: only the customer details, nothing else
CustomerDAO: only data accessor methods related to customers
DatabaseManager: manage database connection, DatabaseConnectionManager might be a better name


But they can be improved.

Customer

If you can make its fields final, make them final.

No need to call super() in a class whose parent is Object. You can just delete that line.

CustomerDAO

The throws SQLException declarations make this class database specific. In theory, a CustomerDAO could work over a web service or a CSV file. Actually CustomerDAO should be an interface, to model a backend-agnostic concept, with throws declarations that are backend-agnostic. Then an implementation using a database backend should wrap the SQLExceptions and throw the backend-agnostic exceptions instead. In such design you will have the flexibility to replace the DAO with a different backend.

Also, the public empty constructor is pointless.

DatabaseManager

The modern pattern of implementing singletons is this:

public enum DatabaseManager {

    INSTANCE;

    // ...
}


This is truly thread-safe. Use this instead of a private static field, which is not truly thread-safe.

Use a framework

Instead of managing database connections yourself, I strongly recommend using a framework that can greatly simply it for you. For example Spring Framework.