Leaking of Data Access Code to Domain Model and Application Services in OCH Architecture.
All Data Access Patterns, defined by Martin Fowler, this a mixiing of Persistence and Domain Logic in the Patterns. And these Patterns has been used a lot int the past by developers. Time and agin develoers forget this and go on mixing the Domain Logic and Persistence Logic.
Rememebr.
Domain Model is pure OO API, it has not trappings of the Data Access or Data Save Code.
If there is no rich model, then this model is Anemic domain model.
All Data Access goes to the Data Project.
Whether it is
One Table One Row Data Access Code
One Table Multiple Rows Data Access Code
Multiple Table Multiple Rows Data Access code
This Code should not leak to the
1. Domain Model Project
2. Application Service Project
In the same way, Infrastructure and CCCs are also the Details.
Their Code should also do not leak to the Domain Model or AS Project.
All Data Access Patterns, defined by Martin Fowler, this a mixiing of Persistence and Domain Logic in the Patterns. And these Patterns has been used a lot int the past by developers. Time and agin develoers forget this and go on mixing the Domain Logic and Persistence Logic.
Rememebr.
Domain Model is pure OO API, it has not trappings of the Data Access or Data Save Code.
If there is no rich model, then this model is Anemic domain model.
All Data Access goes to the Data Project.
Whether it is
One Table One Row Data Access Code
One Table Multiple Rows Data Access Code
Multiple Table Multiple Rows Data Access code
This Code should not leak to the
1. Domain Model Project
2. Application Service Project
In the same way, Infrastructure and CCCs are also the Details.
Their Code should also do not leak to the Domain Model or AS Project.
No comments:
Post a Comment