Tag SoC
Having the domain model separated from the persistence model
In this post, I’d like to write about a pretty common discussion in DDD circles: should one have the domain model separated from the persistence model? In other words, should you map your domain objects to the DB tables directly using an ORM or would it be better to use a separate set of Data Access Objects (DAOs) instead?
Cohesion and Coupling: the difference
This is another post on the most valuable principles in software development.
You might have heard of a guideline saying that we should aim to achieve low coupling and high cohesion when working on a code base. In this article, I’d like to discuss what this guideline actually means and take a look at some code samples illustrating it. I also want to draw a line between these two ideas and show the differences in them.
Separation of Concerns in ORM
Last week we compared Entity Framework and NHibernate from a DDD perspective. Today, I’d like to dive deeper into what Separation of Concerns (SoC) is and why it is so important. We’ll look at some code examples and features that break the boundaries between the domain and persistence logic. Separation of concerns in ORM There are several concerns we deal with in software development. In most applications, there are at least three of them clearly defined: UI, business logic and database.
