I'm reading the architectural patterns chapter of POEAA, and Fowler says that "As the domain logic gets more complicated and you begin moving toward a rich Domain Model (116), the simple approach of an Active Record (160) starts to break down. The one-to-one match of domain classes to tables starts to fail as you factor domain logic into smaller classes. Relational databases don't handle inheritance, so it becomes difficult to use strategies [Gang of Four] and other neat OO patterns. As the domain logic gets feisty, you want to be able to test it without having to talk to the database all the time."
I didn't really understand this. By "one to one match of domain classes to tables", does he mean that only for classes where there is no associations or single table inheritance hierarchy?
And why does factoring domain logic into smaller classes cause the pattern to fail?
What he's trying to say is that more complex domain models are usually more than just "data from a table". These more complex models Fowler is talking about are models that get data from different tables, views or maybe even other sources.
The Active Record pattern is not very suitable for this purpose, and the DataMapper pattern combined with just model classes (containing just the business logic and do not communicate with the data access layer) is probably more suitable in situations like these.
The Active Record pattern fails here, because it maps more or less directly to a table in the database.
I don't know the exact pattern definition, so please correct me if i'm wrong.
No, I think he is talking about the domain logic. With active record the object carries both data and behavior. So that is a one-to-one match. If you start separating data/behaviour, like in the Data Mapper pattern, it becomes one-to-many. I have the impression that you sometimes really have to read that book like academic nonsense to understand what he means. :-)
来源：https://stackoverflow.com/questions/5624319/why-does-active-record-pattern-not-work-with-rich-domain-models