This post originated from an RSS feed registered with .NET Buzz
by Christian Horsdal.
Original Post: Domain Models Should Not Depend on Data Layers
Feed Title: Horsdal
Feed URL: http://www.horsdal-consult.dk/feeds/posts/default
Feed Description: A blog that will be about code, architecture, design, and .NET.
This is the first of 4 posts about how to go about moving from an architecture where the Domain Model depends on the Data Acces component, to an architecture where that dependency is reversed.
In this post I outline the problem that I propose solutions for in the next posts.
Why Write About This? Because I see this problem repeatedly in code that I get to work with. So I might as well write down what I tend to talk to clients about in those situations.
Why Do So Many Domain Models Depend on a Data Access Component? I think there are several reasons, but the most important one it seems to me is that for many this seems to be the default for any server side software:
So that's how many systems start out. Or so it seems from my experience. At some point in the life time of the system the Business Logic component is repurposed as a Domain Model - this may happen is an attempt to get away from Transaction Scripts, or simply because having a Domain Model is seen as The Right Thing To Do (™).
Why Reverse the Dependency? As long as the Domain Model depends on the Data Access component both are hampered. Albeit for different reasons.
Having the Domain Model depend on Data Access layer is a violation of the Dependency Inversion Principle because the Domain Model is a higher level of abstraction than the Data Access component. The consequence is that the Domain Model is tighter coupled to the details of Data Access than it should be leading the poorer maintainability and poorer testability. In fact Domain Models should be POCOs with no other dependencies than the standard library.
Having all other component depend - directly or indirectly - on the Data Access component, makes the Data Access code harder and more risky to change because it potentially effects everything else. The Data Access component is at the edge of the system and just like the entire system should not depend on the Prensentation component (another component at the edge) the entire system should not depend on the Data Access component.
Previous Topic
