You have the profile link to a very good book by Martin Fowler: martinfowler.com/books.html#eaa
Her Pro Active Record: martinfowler.com/eaaCatalog/activeRecord.html
Table Data Gateway: martinfowler.com/eaaCatalog/tableDataGateway.html
Data Mapper: martinfowler.com/eaaCatalog/dataMapper.html
Now a little reasoning from personal experience.
Binding your domain model to a relational complex based on the following factors:
* Granularity (domain model often has greater detail)
* Inheritance (need to Express in a relational data schema)
* Identity (determined by the equality but the code and ID in DB)
* Association (one-to-many is expressed in the code array in the database schema using foreign keys)
* The navigation (in the code — links in the database schema joins)
In the case that the domain model is complex, and we face many of the listed difficulties, it is recommended to use a Data Mapper. This will allow the domain objects to not worry about the existence of the database.
If the subject field is not too complex, it may be convenient to add Persistence methods to the domain model classes (Active Record). This will make it easier for programmers the process of writing the service code.
If your domain model fits well into the relational schema, but we still want to isolate the SQL for the compliance with the principle of personal responsibility, it is recommended to use a Table Data Gateway
This is a pretty common word. If you ask a question, I will be glad to clarify and reply :)