Domain Logic Patterns Martin Fowler

In CRUD of Simple Domains the Screens are mostly Forms Over Data or Forms Over Tables.

All the Business Rules or Data Validation Rules are at the Form Level.

Once the Data is Validated on the Form, it goes directly to the DB. There is not further Data Validation Checks.

In such situation, Domain Model is Anemic Domain Model, it has classes with Data Members and
Getter and Setter Properties. No Domain Logic Methods.

After Passing Form Validation, Data is not further Validated by fetched Data From the DB. No more Validation on the Server Side.

=============================================

Form Validation based Business Logic need in Simple CRUD Domains
Complex Server Side Data Validation after passing the Form Validation, needed in complex CRUD Domains.

=============================================
Separation of Domain Data + Domain Logic from the Persistence Logic is the key.

Row Data Gateway, Active Record Pattern, Table Data Gateway either

1. Do not discuss the Domain Logic they are only focused on Persistence Logic only.
2. They Mix the Domain Data + Domain Logic and Persistence Logic in one class.

Data Mapper Patterns is only Pattern that separate them. Put the Domain Data and Domain Logic in the Domain Model. Persistence Logic is kept inside the Data Mapper Pattern.

Repository Pattern along with the Data Mapper Pattern, along with the Domain Model, along with the Service Layer  is the killing combination and all are combined in the OCH Architecture.

Data Mapper + Repository + Domain Model + Service Layer = OCH Arch

==============================================
Domain Logic Patterns Martin Fowler
Four Patterns

1. Table Module
2. Transaction Script
3. Domain Model
4. Service Layer

1. Table Module tells that all Table Specific & Domain Oriented Data Access Code should be in the separate Class. There is no use of doing this. Data Access Code should not be the part of Business Layer. It should be the part of Data Mapper Pattern defined for that Table. Composite Business Operations, involving 3 tables, are composed by Calling the Table Module classes of those 3 tables. This orchestration class is not recommend. Summary, Orchestration Logic goes into one business Class and Data Access Logic goes into another Class. There is no involvement of Data Access Class.
Above is extracted from RAM N videos. I doubt this.
Orchestration Business Class ==> Table Module Business Class ==> ????
Simple CRUD Domain. Anemic Domain Model. Forms Over Data, Form Validation Only, No On-Server Data Validation

===============================================

2. Transaction Script. Transaction Script goes on to the other extreme. It houses all the Orchestration Logic and Data Access Logic in one class. Again Data Access layer is not discussed. All interactions with 3 tables is done inside the Business Class. There is no involvement of Data Access Class.
Above is extracted from RAM N videos.I doubt this.
Transaction Script Buiness Class ==>  ??????
Simple CRUD Domain. Anemic Domain Model. Forms Over Data, Form Validation Only, No On-Server Data Validation

====================================================

3- Domain Model. Rich OO Domain Model for Server Side Data Validation. Work in combination with Repository + Domain Model + Service Layer Pattern. Hold the Domain Logic. Same as DDD Domain Model. DDD has extracted Pattern with in Domain Model. DDD is about separation of Domain Model. Table based Data Access Logic is placed inside the Data Mapper Pattern. It hold both CRUD Data Access Logic and Domain Oriented or Scenario Oriented Data Access Logic.
No Orchestration Logic and Application Logic
Data Mapper + Repository + Domain Model + Service Layer = OCH Arch

4. Service Layer. Same as DDD Application Service Layer. Hold Orchestration Logic and Application Logic like CCCs. No Domain Logic.
Data Mapper + Repository + Domain Model + Service Layer = OCH Arch