The Active Domain Object pattern has the following consequences:

Has clean application code— Application code that works exclusively with domain objects is much cleaner and easier to develop and maintain than code that includes data model and data access details. When an application uses well-defined domain objects that expose only logical operations, its code can focus more on its own business logic.
Decouples application code from the data model— When you relieve application code of the responsibility for understanding a data model, you are in a better position to alter the data model later.
Groups related data access code into a single component— One or more related active domain objects implement the entire set of data access operations for a set of similarly related tables in the database. Grouping these operations together within a single component makes it easier to identify and repair defects in the data access implementation.

Spreads data access across multiple domain objects— Each active domain object is responsible for its own data access implementation. Spreading this responsibility across multiple objects means that employing overall data access strategies like statement caching requires you to update analogous code in every active domain object implementation.
Limits application control of data access— Application code is limited to the logical attributes and operations that domain objects define. When domain objects are not well-designed or versatile enough for an application's data access requirements, the application code may need to resort to unnatural or awkward workarounds that ultimately lead to unexpected results.