views:

274

answers:

3

I have been trying to learn and apply domain driven concept into my software development. The first thing that I try to do is creating my domain model based on business logic needs. I often also use OR Mapping tool, such as LLBLGen, NHibernate, or Linq to SQL, to create data model and data access layer. The domain model and data model, however, are often very similar which make me wonder what benefit I really get by maintaining two models.

Can someone share their practical thoughts about domain driven design? Furthermore, how would you deal with data model or data access layer when applying DDD in your application?

Thanks in advance.

EDIT

Found a good article, with sample code, about Repository Pattern.

+2  A: 

We map domain objects directly to the database, means that we do not have separate layer for data access, and rather we treat this as infrastructure code.

We use Fluent NHibernate for most of the configuration.

Mike Chaliy
Have you ever run into the case where your data model doesn't fit exactly what your business logic needs? How do you deal with those cases? Thanks.
weilin8
This depends. Fluent NHibernate provides way to override auto-deducted configuration. Means that you can have 90% of your mode automapped and then you provide manual configuration for the rest. However if chances that your data model will largely incompatible (e.g. legacy or crazy dba), I think better to have real dataaccess layer to act as abstraction layer.
Mike Chaliy
+3  A: 

I abstract my data access via the Repository pattern, so keep my domain objects completely POCO and data provider agnostic.

This allows me to sculpt my application from a domain perspective, concentrating on the logic, primarily via Unit Tests.

Once this has settled I put in the Presentation layer (usually web pages) and then commit to the concrete database schema. I then implement my concrete Repository classes, which can be L2S.

I've drafted a couple of articles here - http://www.duncangunn.me.uk/dasblog/2009/04/11/TheRepositoryPattern.aspx http://www.duncangunn.me.uk/dasblog/2009/06/27/MockingLinqToSQLRepositories.aspx

Keep an eye out over the next couple of weeks as I will be documenting and providing sample code of my implementation which uses Unit of Work pattern also.

Duncan
+2  A: 

Splitting bounded contexts is also a big DDD benefit, you resolve each problem in its context, even if you must duplicate data between contexts.

Good aggregate roots definition gives a simpler design and leads to potential performance improvement (scalability through grid computing, see Gojko Adzic post).

When your design becomes really Domain Driven, your applications is more supple to new business needs, because implementation becomes really an implementation detail.

Think Before Coding