ORM and DDD layers

All,

Me and my programming team are using DDD on our first project. So far it has 
been very exciting to all of us. There are four of us on the team.

We have hit a point of discussion that none of us can seem to figure out. So 
I figured I'd come ask the experts!

We are using Microsoft .NET for the development of this project, I know DDD 
really isn't technology specific, but I wanted to let everyone know what we 
are using in case others have hit this point too.

We are using the Microsoft entity framework for our infrastructure.database 
layer. Our choices are nhibernate or the Microsoft entity framework.

The problem we are having is understanding how the entity framework and 
domain layer work together in DDD.

The entity framework returns entities that are I guess domain layer objects 
related directly to a table in the database and are already populated with 
data.

In our research, we have seen things such as the infrastructure.dataaccess 
layer being sql that is executed against the database for the data and in 
turn, the infrastructure layer requests a domain entity from the domain 
layer. The infrastructure layer then creates the domain entity and populates 
it with data from the database. The infrastructure layer then returns the 
inflated domain object to the caller which could be a repository or service 
layer.

Re: ORM and DDD layers

Hi Justin,

First up, I'd say to read up on Repositories - you mention them in  
passing in your post, but that's really where the action happens  
between your domain and infrastructure, so make sure you're fully  
clued in with them.

Secondly, there are two basic ways you can go with an ORM in DDD:

1. Use the objects that your ORM instantiates as your domain objects  
(and design them as such)
2. Map between your ORM objects and your domain objects

Option 1 is the most common I've seen, but it usually imposes certain  
restrictions on how you can shape your domain and instantiate your  
objects. Different ORMs will give you different amounts of pain in  
this regard.

Option 2 gives you full control over the shape and lifecycle of your  
domain objects (including instantiation), but you will need to write  
more glue code, especially if you need some features that you get for  
free with an ORM, such as lazy loading and automatic unit-of-work  
management. This option is not too removed from the examples you  
describe, although there'd be less/no SQL.

So, if you want to keep your domain as pure as possible, or you're  
stuck with an especially nasty DB schema, go with Option 2 - if you  
want the pragmatic, and hopefully quicker approach, go with Option 1.

That'd be my two cents anyway.

Re: Summary vs. Fully Hydrated Aggregate Roots

Thanks guys, I think you've answered the question as to how to deal with related objects, but what about when
I only need a few of the properties of the object? I don't see a way around this other than maintaining a
separate "summary" object that doesn't query for all the properties from the persistent store.

--- In domaindrivendesign <at> yahoogroups.com, "J Searles" <bleufunk@...> wrote:
>
> You might find that you'd be better off pulling some of those collections out of the aggregate - make your
relations implicit instead of explicit. Then from your OrderRepository, have a method to retrieve
OrdersByCustomer when you do need them. 
> 
> Alternately, you can create DTOs to collect and summarize the data you want to send to the UI, though these
objects should not be part of your domain.
> 
> As mentioned, an ORM with lazy-loading implemented would solve the heavy lifting, but i've found that
making my model tighter with implicit relations makes for a cleaner, more supple model.
> 
> --- In domaindrivendesign <at> yahoogroups.com, "Jayme Edwards" <eavonius@> wrote:
> >
> > Hello,
> > 
> > I have a Customer aggregate root that has 20 simple type properties and 10 collections that provide
access to related aggregate roots (orders etc.). I'm building a web application and trying to use DDD. 
> > 
> > I have one page of my web application that lets an administrator list the customers in a grid. The grid only
shows 5 of these properties and uses one of the relationships to display the data in this page.
> > 
> > I have another page that lets the administrator configure everything about that customer. This page
needs the Customer to be fully "hydrated" meaning it accesses all the properties and collections.
> > 
> > I don't want to load all the data on the first page. My question is, would it be a better practice to define

Re: ORM and DDD layers

Hi Mike,
From: "Michael Hart" <michael.hart.au <at> gmail.com>
To: <domaindrivendesign <at> yahoogroups.com>

1. Use the objects that your ORM instantiates as your domain objects
(and design them as such)

Thanks for the response.

This was one strategy that we discussed. Simply using the Microsoft entity 
framework ORM entities as our domain entities and leave it at that. However, 
again, the pickle is that the ORM is in the infrastructure layer and this 
then would totally abolish the domain layer.

However, if we needed exact business rules, for example on the employee 
entity that the ORM generated in the infrastructure layer, how would we 
extend the ORM employee entity to have a method to have the business rule in 
place?

One developer on our team suggested that we inherit the ORM employee in the 
domain layer and extend it there to have the business rule. However, this 
then would make the domain layer reliant on the ORM in the infrastructure 
layer. I'm not sure that is the path we would want to go.

We then discussed mapping like you suggested... in the repository... getting 
the ORM employee, then the domain layer employee, and mapping the ORM 
employee to the domain employee then returning, for example, the domain 
employee to the caller/service etc.

Obviously our domain layer entities will need to have exact business rules, 

entities and value objects

Re: ORM and DDD layers

Justin,

If you're sticking with EF and choosing Option 1, then I'd look into  
the EF POCO adapter:

http://code.msdn.microsoft.com/EFPocoAdapter

Then you can try to create your domain objects to be as persistent  
ignorant as possible, including whatever business rules and validation  
logic you need. You won't achieve full de-coupling, but hopefully  
you'll get close. All the infrastructure-specific code will happen in  
your Repositories.

Also, probably best to check out Eric Evans' book if you're really  
dedicated to using DDD.

Cheers,

Michael

On 01/04/2009, at 2:34 PM, Justin Daubenmire wrote:

> Hi Mike,
> From: "Michael Hart" <michael.hart.au <at> gmail.com>
> To: <domaindrivendesign <at> yahoogroups.com>
>
> 1. Use the objects that your ORM instantiates as your domain objects
> (and design them as such)
>
> Thanks for the response.
>
> This was one strategy that we discussed. Simply using the Microsoft  
> entity
> framework ORM entities as our domain entities and leave it at that.  
> However,
> again, the pickle is that the ORM is in the infrastructure layer and  
> this
> then would totally abolish the domain layer.
>
>
> However, if we needed exact business rules, for example on the  
> employee
> entity that the ORM generated in the infrastructure layer, how would  
> we
> extend the ORM employee entity to have a method to have the business  
> rule in
> place?
>
> One developer on our team suggested that we inherit the ORM employee  
> in the
> domain layer and extend it there to have the business rule. However,  
> this
> then would make the domain layer reliant on the ORM in the  
> infrastructure
> layer. I'm not sure that is the path we would want to go.
>
> We then discussed mapping like you suggested... in the repository...  
> getting
> the ORM employee, then the domain layer employee, and mapping the ORM
> employee to the domain employee then returning, for example, the  
> domain
> employee to the caller/service etc.
>
> Obviously our domain layer entities will need to have exact business  
> rules,
> for example applying a 15% tax increase on x,y,z type employees etc.  
> The ORM
> cannot give us this functionality. All the orm can do is create what  
> it
> calls an entity that is populated with data from the database and  
> return it.
>
> hmmmmm.
>
>
> Anyone have any other thoughts on this situation? How do others  
> handle this
> situation using an ORM?
>
> Thanks Mike and others for the input!
>
> Regards,
> Justin
> ----- Original Message -----
> From: "Michael Hart" <michael.hart.au <at> gmail.com>
> To: <domaindrivendesign <at> yahoogroups.com>
> Sent: Tuesday, March 31, 2009 10:36 PM
> Subject: Re: [domaindrivendesign] ORM and DDD layers
>
>
>> Hi Justin,
>>
>> First up, I'd say to read up on Repositories - you mention them in
>> passing in your post, but that's really where the action happens
>> between your domain and infrastructure, so make sure you're fully
>> clued in with them.
>>
>> Secondly, there are two basic ways you can go with an ORM in DDD:
>>
>> 1. Use the objects that your ORM instantiates as your domain objects
>> (and design them as such)
>> 2. Map between your ORM objects and your domain objects
>>
>> Option 1 is the most common I've seen, but it usually imposes certain
>> restrictions on how you can shape your domain and instantiate your
>> objects. Different ORMs will give you different amounts of pain in
>> this regard.
>>
>> Option 2 gives you full control over the shape and lifecycle of your
>> domain objects (including instantiation), but you will need to write
>> more glue code, especially if you need some features that you get for
>> free with an ORM, such as lazy loading and automatic unit-of-work
>> management. This option is not too removed from the examples you
>> describe, although there'd be less/no SQL.
>>
>> So, if you want to keep your domain as pure as possible, or you're
>> stuck with an especially nasty DB schema, go with Option 2 - if you
>> want the pragmatic, and hopefully quicker approach, go with Option 1.
>>
>> That'd be my two cents anyway.
>>
>> Cheers,
>>
>> Michael
>>
>> On 01/04/2009, at 12:05 PM, Justin Daubenmire wrote:
>>
>>> All,
>>>
>>> Me and my programming team are using DDD on our first project. So
>>> far it has
>>> been very exciting to all of us. There are four of us on the team.
>>>
>>> We have hit a point of discussion that none of us can seem to figure
>>> out. So
>>> I figured I'd come ask the experts!
>>>
>>> We are using Microsoft .NET for the development of this project, I
>>> know DDD
>>> really isn't technology specific, but I wanted to let everyone know
>>> what we
>>> are using in case others have hit this point too.
>>>
>>> We are using the Microsoft entity framework for our
>>> infrastructure.database
>>> layer. Our choices are nhibernate or the Microsoft entity framework.
>>>
>>> The problem we are having is understanding how the entity framework
>>> and
>>> domain layer work together in DDD.
>>>
>>> The entity framework returns entities that are I guess domain layer
>>> objects
>>> related directly to a table in the database and are already
>>> populated with
>>> data.
>>>
>>> In our research, we have seen things such as the
>>> infrastructure.dataaccess
>>> layer being sql that is executed against the database for the data
>>> and in
>>> turn, the infrastructure layer requests a domain entity from the
>>> domain
>>> layer. The infrastructure layer then creates the domain entity and
>>> populates
>>> it with data from the database. The infrastructure layer then
>>> returns the
>>> inflated domain object to the caller which could be a repository or
>>> service
>>> layer.
>>>
>>> So, how does the entity framework fit into this mold? The entity
>>> framework
>>> has entities already instantiated and all data mapped in them from  
>>> the
>>> database directly at the infrastructure.dataaccess layer and never
>>> needs the
>>> domain layer to get a domain layer entity.
>>>
>>> Some questions we are pondering....
>>>
>>> If the entity framework in the infrastructure layer is getting the
>>> data and
>>> inflating the entity for us, then how do we use domain objects?
>>> Entities are
>>> in the domain but the entity framework has seemed to combine the
>>> concept of
>>> a domain entity and the database together.
>>>
>>> Can someone please help me understand how to use entity framework in
>>> DDD?
>>> Perhaps the entity framework is not a good orm to use? I know that
>>> there is
>>> nhibernat for .net and hibernate for java. Are those more suited for
>>> DDD
>>> rather than the entity framework?
>>>
>>> Thanks to everyone for any opinion, feedback, and help... all of it
>>> welcomed
>>> and appreciated!
>>>
>>> /Justin
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

------------------------------------

Re: entities and value objects

Re: ORM and DDD layers

Re: ORM and DDD layers

There is nothing like a good ORM that allows one to your Domain Objects clean without much fuss.

If that is not possible you can always hinherit or do something like the following:

class Customer 
{
   CustomerEntity _Data;

   // operations

}

Both have pros and cons. The con of this approach as that you will have to mantain two class hierachies (an
Entity Hierarchy and a Domain Object Hierachy) which is a lot of work!!! Furthermore you might end up with a
class hierarchy that is dependent on the Entity Framework as well once you start to "simplify" stuff as
deadlines each closure and you are late.

You can also use code generators that given you MSEntity it generates the Domain Object class (code) to ease
the pain.

Unless you plan to change ORM in the middle of the project and you need to use Entity Framework for some
reason, then I would trust the framework and go for Hinheritance. Most people trusts the ASP.NET
framework so why not trust the MS Entity Framework?

I always considered that the hability to change an ORM for another is more of a reaseach objective then a
practical one unless you have the budget. Try to explain the benefit of that to your sponsor, for sure you
will understanding person with no budget for that.

The bottom line choose your ORM wisely. Once you do, just bite the bullet and take ownership of that decision.

Nuno
PS: I prefer NHibernate by the way.

------------------------------------

Re: ORM and DDD layers

>
OTOH, EF entities have to inherit from EntityObject which directly couples
the entities to infrastructure
<

Sure it links them to EF, but why is that a problem?  If I write the classes 
in C# it links them to a language, or .NET.  In NH you have to make 
everything virtual if you want lazy loading, that's a framework requirement 
too.

Pete
====
http://mrpmorris.blogspot.com 

------------------------------------