Point 1 Patterns are a means to simplify communication about various concepts. Patterns are not intended to be used as LEGOs where they snap together and solve problems. Combinations of concepts may help resolve a problem, but you should not expect to be able to simply pick and choose patterns for your needs. First and foremost, they are a communication aid.
Domain logic !=
Business logic, and I think this is the crux of your misunderstanding.
Active Record and Data Mapper are
Data Source Architectural Patterns.
Transaction Script and Domain Model are
Domain Logic Patterns.
And he defines them as:
An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.
A layer of Mappers (473) that moves data between objects and a database while keeping them independent of each other and the mapper itself.
Organizes business logic by procedures where each procedure handles a single request from the presentation.
An object model of the domain that incorporates both behavior and data.
You mentioned that Fowler suggests using
Data Mapper with Transaction Script
Active Record with Domain Model
and that you didn't understand the following aspects.
Transaction Script classes contain business logic and data logic
Which isn't correct. Transaction script groups together similar business logic and doesn't say anything about data logic.
Domain Model separates business logic and data logic
Domain Model doesn't address business logic or data logic. It puts together rules that are domain specific. Those could be considered business rules, but they're not. Domains have inherent rules to them that all businesses must conform to. External regulation is a good example of domain logic that is not necessarily business logic, but still rules that must be conformed to.
Active Record combines business logic and data logic
No, Active Record merely deals with data logic and provides a wrapper around what may be a very complicated storage mechanism for the data. No business logic here.
Data Mapper separates business logic and data logic
Factually, this is true, but that's disingenuous for this question. Data Mapper is an isolation layer. It would be a useful approach if there were multiple data sources to glom together.