Leaking Application Logic to Data Access Class

Leaking Application Logic to Data Access Class

Execution of Application and Domain Logic

Calling the Domain Logic inside the Domain Objects is the Application Logic.

One thing to remember, Application Services are center of Orchestration and execution of Application and Domain Logic. Application Services should be thin and Use Case oriented. If they are Fat there are changes we may delegate the Application and Domain Logic to the Data Access Class. This is anti-pattern.

Data Access class should only fetch and save data. In case of save, when Domain objects reached inside the Data Access class, they are already validated inside the Application Service. No more validation is done inside the Data Access Class. Leaking of App or Domain logic to App. Service is an anti-pattern. We should never ever call the Domain Obj Methods/Behaviors inside the Data Access Class while saving data. Calling the Domain Logic inside Domain Objects is the Application Logic. Data Access Class should only access the Data within the Domain Obj. Only Valid Domain Objects should be passed to the Data Access Class. Otherwise our Data Access class will be doing Validation + Data Access. No SOC. Hard to Test. Violation of SRP.

For Saving Data

View è Controllerè AS è Repository+UOW Class: 5 Patterns è EF è DB

For executing Application Logic and Business Logic

Controller è AS è Factories/Domain Services/Entities/VO/Aggregates Roots/ Domain Events