ddd and relational databases - persisting value objects

Hi,

I did a talk on monday in London on persisting value objects and 
different options available for that. The write-up is now online at

http://gojko.net/2009/09/30/ddd-and-relational-databases-the-value-object-dilemma/

and for those more keen on watching than reading, skills matter filmed 
the event so the video is available as well:

http://skillsmatter.com/podcast/design-architecture/ddd-and-relational-databases-the-value-object-dilemma

--
gojko adzic
http://gojko.net

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

RE: Re: Are Bounded Contexts Physical or Logical?

Thanks for the insight.

Comments inline below,

> 	From: domaindrivendesign <at> yahoogroups.com
[mailto:domaindrivendesign <at> yahoogroups.com] On Behalf Of vvernon_shiftmethod

>	Sent: 30 September 2009 15:58
>	To: domaindrivendesign <at> yahoogroups.com
>	Subject: [domaindrivendesign] Re: Are Bounded Contexts Physical or
Logical?
>
>	I am not sure I discern how you think you are using Application
Services. Recall that a service in the Application Layer (glue,
transactions, etc) is different from a service in the Domain Layer
(stateless domain business logic). You can create whatever services in the
Application Layer that you need in order to use one or more BCs. Thus, you
could have an Application Service using Domain Services in one or more BCs,
and doing some result aggregation and driving workflow from the results.
>	

	That paragraph sums up what I was wanting to know. I do currently
use Application Service and Domain Services as you describe though my
Application Service is mostly just acting as a Façade of all the Domain
Components (Domain Service, ARs, Repositories, etc) in a BC. This is
needlessly complicating my Application Services as I am passing messages
(via a service bus) between each Application Service to get all the
information and/or perform all the tasks required to complete a request.
This is where I think I'm going seriously wrong.

Re: Specification performance

Hi(Merhaba :) ) Inanc ,
I had a similar requirement before but Aspecially if you want to generic solution running Specifications
both on Database and Memory collections requires a lot of work for a "rolling your own" solution. 

You need to construct AST tree and then convert tree to HQL,SQL whatever you need... in .NET space, LINQ is
designed for this and also  there is NHibernate LINQ provider for this. But As far as I know in Java there is no
easy way to do this. 

Cihat Altuntaþ

--- In domaindrivendesign <at> yahoogroups.com, "Inanc Gumus" <inanc.gumus@...> wrote:
>
> Hello Martin,
> 
> --- In domaindrivendesign <at> yahoogroups.com, Martin Nilsson <mffmartin@> wrote:
> >
> > http://tech.groups.yahoo.com/group/domaindrivendesign/message/14854
> > 
> 
> Before I post my message I have red that post too, also did a very time-consuming search on a search engine
too. After failed attempts, I have decided to post something like this here.
>

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

Re: Are Bounded Contexts Physical or Logical?

> That paragraph sums up what I was wanting to know. 

Great!

> I'm still uncertain how the underlying data store(s) should
> be structured. Would you normally have one Data Store per 
> Application Service or one Data Store per Domain BC?

One per BC (model) is typical.

Think of it this way: Your BC contains a domain model. Your domain model may or may not be persistent. This is
important to acknowledge because DDD and domain models are not about persistence. They are about
modeling your domain. If it is persistent, and it is in most enterprise business cases, you have an object
store of some kind backing your domain model. The object store is very likely managed via O-R mapping,
using N/Hibernate or TopLink, and mapped down to a relational database. Your model to data store is a 1:1
relationship. Now just apply this knowledge to each BC's model.

It is possible that two or more BCs could use the same persistence store, but you'd need to have very specific
reasons to do that (e.g. an entity in one BC is used as a value object in another BC, but both renditions of the
same data are persisted to the exact same place; this is probably rare, so don't let it confuse you if you
don't need it). Just remember that persistence is implementation detail that can get nasty, but the model
is pure (as possible).

CQS is an old approach to object design. Basically, a command can be as simple as this:

aPhone.changeLocation(aChangePhoneLocationCommand);

And a query can be as simple as this:

PhoneLocation location = aPhone.getLocation();

RE: Re: Are Bounded Contexts Physical or Logical?

ORM impediments for DDD

I usually feel limited for domain model design using DDD/OO techniques due to being coupled to the ORM
world. 
Domain concepts are lost and so not included in the domain model because of thinking in table relations and
how ORM tools do the mapping.
OODBMS fix these kind of stuff and let me think in term of graph objects, without being tighed to table relations.
I usually hide domain concepts within an AR repository and hidratate an AR with those DDD-OO concepts when
the AR it asked, so I see myself forced to alter the AR dependence graph behind an AR repository to
fill/hidratate it with objects that ORM tools don't deal with.

How do you people treat this impediments when dealing with ORM tools?

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

Re: Are Bounded Contexts Physical or Logical?

Okay, thanks for clarifying. So the separate BCs in the case of CQRS are eventually consistent. One is used
to store events (Event Sourcing commands) and the other stores the query data (what the DTOs are built from).

How has CQRS/BASE worked out for you?

Vaughn

--- In domaindrivendesign <at> yahoogroups.com, "Ben Ellis" <DragonWolf@...> wrote:
>
> Thanks Vaughn
>  
>      That's really helps me figure out how everything in DDD fits together.
> I understand and have implemented CQS as you've described, the bit I was
> refering to was CQRS (
> <http://codebetter.com/blogs/gregyoung/archive/2009/08/13/command-query-sepa
> ration.aspx>
> http://codebetter.com/blogs/gregyoung/archive/2009/08/13/command-query-separ
> ation.aspx) about using seperate end-points/BCs/Data Stores for Command
> Processing and Query Processing.
>  
>         Ben
> 
> 
>   _____  
> 
> From: domaindrivendesign <at> yahoogroups.com
> [mailto:domaindrivendesign <at> yahoogroups.com] On Behalf Of vvernon_shiftmethod
> Sent: 01 October 2009 18:28
> To: domaindrivendesign <at> yahoogroups.com
> Subject: [domaindrivendesign] Re: Are Bounded Contexts Physical or Logical?
> 
> 
>   
> 
> > That paragraph sums up what I was wanting to know. 
> 
> Great!
> 
> > I'm still uncertain how the underlying data store(s) should
> > be structured. Would you normally have one Data Store per 
> > Application Service or one Data Store per Domain BC?
> 
> One per BC (model) is typical.
> 
> Think of it this way: Your BC contains a domain model. Your domain model may
> or may not be persistent. This is important to acknowledge because DDD and
> domain models are not about persistence. They are about modeling your
> domain. If it is persistent, and it is in most enterprise business cases,
> you have an object store of some kind backing your domain model. The object
> store is very likely managed via O-R mapping, using N/Hibernate or TopLink,
> and mapped down to a relational database. Your model to data store is a 1:1
> relationship. Now just apply this knowledge to each BC's model.
> 
> It is possible that two or more BCs could use the same persistence store,
> but you'd need to have very specific reasons to do that (e.g. an entity in
> one BC is used as a value object in another BC, but both renditions of the
> same data are persisted to the exact same place; this is probably rare, so
> don't let it confuse you if you don't need it). Just remember that
> persistence is implementation detail that can get nasty, but the model is
> pure (as possible).
> 
> CQS is an old approach to object design. Basically, a command can be as
> simple as this:
> 
> aPhone.changeLocation(aChangePhoneLocationCommand);
> 
> And a query can be as simple as this:
> 
> PhoneLocation location = aPhone.getLocation();
> 
> The principles of CQS simple state that asking a question doesn't change the
> answer. Commands are not questions, and questions are not commands.
> 
> If your Application Service is receiving messages from MOM, that's not your
> domain. It's in a completely separate layer. (See DDD p107.) If you take
> your MOM message and turn it into a command for your domain, then send that
> command to your domain, you are doing the CQS that many talking about on
> this group of late:
> 
> // in Application Service (Application Layer)
> 
> // MOMMessage messageParam from some bus or queue
> 
> Phone phone = phoneRepository.findPhone(...); // params from messageParam
> 
> ChangePhoneLocationCommand cmd = ...; // CommandFactory or something uses
> params from messageParam
> 
> phone.changeLocation(cmd);
> 
> A lot of this could be housed in a Domain Service (don't pass the
> messageParam itself into the domain unless the object type won't pollute the
> domain! pass the parts), but the point is just to show a MOM message base
> command being different from a domain command. It is possible that you send
> ChangePhoneLocationCommand and other domain command objects serialized
> around on the bus/queue as the message body, but that's a design decision.
> 
> Vaughn Vernon
> 
> --- In domaindrivendesign@ <mailto:domaindrivendesign%40yahoogroups.com>
> yahoogroups.com, "Ben Ellis" <DragonWolf@> wrote:
> >
> > 
> > Thanks for the insight.
> > 
> > Comments inline below,
> > 
> > 
> > > From: domaindrivendesign@ <mailto:domaindrivendesign%40yahoogroups.com>
> yahoogroups.com
> > [mailto:domaindrivendesign@ <mailto:domaindrivendesign%40yahoogroups.com>
> yahoogroups.com] On Behalf Of vvernon_shiftmethod
> > 
> > > Sent: 30 September 2009 15:58
> > > To: domaindrivendesign@ <mailto:domaindrivendesign%40yahoogroups.com>
> yahoogroups.com
> > > Subject: [domaindrivendesign] Re: Are Bounded Contexts Physical or
> > Logical?
> > >
> > > I am not sure I discern how you think you are using Application
> > Services. Recall that a service in the Application Layer (glue,
> > transactions, etc) is different from a service in the Domain Layer
> > (stateless domain business logic). You can create whatever services in the
> > Application Layer that you need in order to use one or more BCs. Thus, you
> > could have an Application Service using Domain Services in one or more
> BCs,
> > and doing some result aggregation and driving workflow from the results.
> > > 
> > 
> > That paragraph sums up what I was wanting to know. I do currently
> > use Application Service and Domain Services as you describe though my
> > Application Service is mostly just acting as a Façade of all the Domain
> > Components (Domain Service, ARs, Repositories, etc) in a BC. This is
> > needlessly complicating my Application Services as I am passing messages
> > (via a service bus) between each Application Service to get all the
> > information and/or perform all the tasks required to complete a request.
> > This is where I think I'm going seriously wrong.
> > 
> > I.e. So instead of Messaging, Routing, Smpp and Anticorruption
> > (Message Sending) Application Services, I could just use one Messaging
> > Application Service that uses the Messaging, Routing and Smpp Domains and
> > the Anticorruption layer to complete Command / Query Requests.
> > 
> > I'm still uncertain how the underlying data store(s) should be
> > structured. Would you normally have one Data Store per Application Service
> > or one Data Store per Domain BC?
> > 
> > > Yes it is acceptable for a single team to be responsible for
> > multiple BCs within a single project. DDD encourages the separation of
> > models that deal with separate concerns, and for teams to focus only on
> the
> > concerns within a given model, not being distracted by what happens
> outside
> > the specific BC or how the specific BC is used. That viewpoint keeps the
> > models pure. If your models have been separated for the reasons of
> > distinction, not arbitrarily, then you have used BCs correctly.
> > 
> > I believe I've separated my models for good reason, whether I've
> > separated them for the right reasons may be open to debate. I've read a
> lot
> > about CQS but still don't fully grasp how to model and implement it. My
> > understanding is I would have an Application Service for Commands and an
> > Application Service for Queries, but they both would use the same Domain
> > Models internally?, or would I have a separate Domain Model for Commands
> and
> > Queries?
> > 
> > > 
> > > Vaughn Vernon
> > 
> > --- In domaindrivendesign@ <mailto:domaindrivendesign%40yahoogroups.com>
> yahoogroups.com
> > <mailto:domaindrivendesign%40yahoogroups.com> , "Ben Ellis" <DragonWolf@>
> > wrote:
> > >
> > > Is it acceptable to seperate BCs Logically? I've written several
> > > libraries using DDDD seperate from each other and each has its own
> > physical
> > > Application Service. Can I re-use these libraries in several
> > different
> > > Application Services?
> > > 
> > > I.e. There is a Phone Number Query BC, that currently queries
> > > information about specific phonenumbers and groups of phone
> > numbers (i.e. UK
> > > Mobile Numbers, UK Landline Number, Irish Mobile Numbers ,etc ).
> > It
> > > currently runs in its own Application Service and receives Query
> > Request
> > > messages and sends Query Response messages. It makes more sense to
> > put drop
> > > the Application Service and instead use the BC within the
> > Application
> > > Services that make use of it.
> > > 
> > > I.e. A Routing Service references the Routing BC and Phone Number
> > > Query BC instead of the Routing Service querying (and caching) a
> > Phone
> > > Number Query Service when it needs information about a specific
> > phone
> > > number.
> > > 
> > > Is it acceptable for the Phone Number Query BC run off the same
> > > table regardless which Application Service it is contained in? Can
> > this
> > > scale simply via replication (or using events to synchronize the
> > data)?
> > > 
> > > All this seems fine to me, but I just want to check if there are
> > any
> > > obvious flaws I'm missing out on.
> > > 
> > > Ben
> > >
> >
>

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

Re: ORM impediments for DDD

Re: ORM impediments for DDD

Re: ORM impediments for DDD