gmane.comp.programming.domain-driven-design

Getting references to internal entities from outside aggregate boundary

I have an entity 'Calibration' which is a variant entity under the
Aggregate 'MixDesign'. MixDesigns create calibrations and calibrations
are only valid as they represent a valuation based on mix design
properties. There is no such thing as a calibration without a mix design.

I have other objects outside the mix design aggregate boundary which
need to know which calibration is being used for their calculation,
but DDD dictates that no references to inner variants are held. 

I have considered moving Calibration to be its own aggregate but this
is awkward since a calibration really only exists as a valuation from
a mix design.

How have other people here dealt with this kind of pseudo-aggregate
reference problem? I really don't want to implement a service to deal
with associations in the domain for something as simple as object
references.
Should I reference the calibration by some kind of business key like
the Creation date (which is unique) or something?
thanks,
mike

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

headers

moffdub | 13 Aug 01:07

Re: Getting references to internal entities from outside aggregate boundary

The edict about aggregates isn't as restrictive as it sounds.

You generally can hold references to internal entities, as long as
they are transient and don't last longer than one operation. Another
technique I use is to allow only the aggregate root's repository to
use the internal entity repository. The implication of this is that
the references to internal entities is done via the aggregate root. 

Yet another technique is to return the internal entities as immutable,
if at all possible.

--- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
<nichols_mike_s@...> wrote:
>
> I have an entity 'Calibration' which is a variant entity under the
> Aggregate 'MixDesign'. MixDesigns create calibrations and calibrations
> are only valid as they represent a valuation based on mix design
> properties. There is no such thing as a calibration without a mix
design.
> 
> I have other objects outside the mix design aggregate boundary which
> need to know which calibration is being used for their calculation,
> but DDD dictates that no references to inner variants are held. 
> 
> I have considered moving Calibration to be its own aggregate but this
> is awkward since a calibration really only exists as a valuation from
> a mix design.
> 
> How have other people here dealt with this kind of pseudo-aggregate
> reference problem? I really don't want to implement a service to deal

(Continue reading)

headers

nichols_mike_s | 13 Aug 01:18

Re: Getting references to internal entities from outside aggregate boundary

I don't understand how this resolves maintaining references to
internal entities in a different aggregate root? 
Maybe I should clarify that I need to persist the 'which one' question
pertaining to the internal entities for consumption outside the
aggregate root...not just for a single operation.

--- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@...> wrote:
>
> The edict about aggregates isn't as restrictive as it sounds.
> 
> You generally can hold references to internal entities, as long as
> they are transient and don't last longer than one operation. Another
> technique I use is to allow only the aggregate root's repository to
> use the internal entity repository. The implication of this is that
> the references to internal entities is done via the aggregate root. 
> 
> Yet another technique is to return the internal entities as immutable,
> if at all possible.
> 
> --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> <nichols_mike_s@> wrote:
> >
> > I have an entity 'Calibration' which is a variant entity under the
> > Aggregate 'MixDesign'. MixDesigns create calibrations and calibrations
> > are only valid as they represent a valuation based on mix design
> > properties. There is no such thing as a calibration without a mix
> design.
> > 
> > I have other objects outside the mix design aggregate boundary which
> > need to know which calibration is being used for their calculation,

(Continue reading)

headers

moffdub | 13 Aug 02:09

Re: Getting references to internal entities from outside aggregate boundary

You're right, I'm probably not getting what your problem is. As I
understand it:

// ...some method in a different aggregate...
{
MixDesign mixForCalc = (new
RepositoryLocator(...)).getMixDesignRepository().findByID(1874);

Calibration calibrationForCalc = mixForCalc.getCalibrationByCriteria(...);

... use calibrationForCalc here for something ...
calibrationForCalc = null; // drop the reference
}

Are you referring to the problem of weak entity types in
Entity-Relationship modeling? In other words, is Calibration's primary
key is entirely dependent on MixDesign's primary key?

--- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
<nichols_mike_s@...> wrote:
>
> I don't understand how this resolves maintaining references to
> internal entities in a different aggregate root? 
> Maybe I should clarify that I need to persist the 'which one' question
> pertaining to the internal entities for consumption outside the
> aggregate root...not just for a single operation.
> 
> 
> --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@> wrote:
> >

(Continue reading)

headers

John Teague | 13 Aug 06:51

Re: Re: Getting references to internal entities from outside aggregate boundary

The important determination for me is whether or not using the Calibration object is being used in the exact same context in each aggregate.

The danger is using the same entity in different contexts is when they are used for similar, but not exactly the same purpose. You run the risk of changing the behavior of the entity to meet the needs of one boundary that has an averse impact on a different boundary.

If the entities are being used in different contexts, you are probably better off with two seperate object to describe their row in each bounded context. Even if these two objects are remarkably similar.

Other options include using a context map or a shared entity. With these options you have a lot more restrictions when making breaking changes. You need to ensure the change works in both contexts.

Which option you choose depends on your environment and domain of course ;) If are working with different teams, then you need more separation to make sure you not walking on each other's feet. If it's a small team working on all of the contexts, then you can be more flexible with your approach.

HTH,
John

On Tue, Aug 12, 2008 at 7:09 PM, moffdub <moffdub <at> yahoo.com> wrote:

You're right, I'm probably not getting what your problem is. As I
understand it:

// ...some method in a different aggregate...
{
MixDesign mixForCalc = (new
RepositoryLocator(...)).getMixDesignRepository().findByID(1874);

Calibration calibrationForCalc = mixForCalc.getCalibrationByCriteria(...);

... use calibrationForCalc here for something ...
calibrationForCalc = null; // drop the reference
}

Are you referring to the problem of weak entity types in
Entity-Relationship modeling? In other words, is Calibration's primary
key is entirely dependent on MixDesign's primary key?

--- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
<nichols_mike_s <at> ...> wrote:
>
> I don't understand how this resolves maintaining references to
> internal entities in a different aggregate root?
> Maybe I should clarify that I need to persist the 'which one' question
> pertaining to the internal entities for consumption outside the
> aggregate root...not just for a single operation.
>
>
> --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub <at> > wrote:
> >
> > The edict about aggregates isn't as restrictive as it sounds.
> >
> > You generally can hold references to internal entities, as long as
> > they are transient and don't last longer than one operation. Another
> > technique I use is to allow only the aggregate root's repository to
> > use the internal entity repository. The implication of this is that
> > the references to internal entities is done via the aggregate root.
> >
> > Yet another technique is to return the internal entities as immutable,
> > if at all possible.
> >
> > --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> > <nichols_mike_s <at> > wrote:
> > >
> > > I have an entity 'Calibration' which is a variant entity under the
> > > Aggregate 'MixDesign'. MixDesigns create calibrations and
calibrations
> > > are only valid as they represent a valuation based on mix design
> > > properties. There is no such thing as a calibration without a mix
> > design.
> > >
> > > I have other objects outside the mix design aggregate boundary which
> > > need to know which calibration is being used for their calculation,
> > > but DDD dictates that no references to inner variants are held.
> > >
> > > I have considered moving Calibration to be its own aggregate but
this
> > > is awkward since a calibration really only exists as a valuation
from
> > > a mix design.
> > >
> > > How have other people here dealt with this kind of pseudo-aggregate
> > > reference problem? I really don't want to implement a service to
deal
> > > with associations in the domain for something as simple as object
> > > references.
> > > Should I reference the calibration by some kind of business key like
> > > the Creation date (which is unique) or something?
> > > thanks,
> > > mike
> > >
> >
>

__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___

headers

nichols_mike_s | 13 Aug 07:57

Re: Getting references to internal entities from outside aggregate boundary

Code would maybe help clarify further...

project.SetSpecMixDesign(MixDesign md){
 mixDesign=md;
}
project.ApproveCalibrationForSpec(Calibration calibration) {
   approvedCalibration = calibration;//but this violates root boundary
  //here is where I need to associate the calibration outside its
aggregate
}

project.GetApprovedCalibrationFactor() {
  return   approvedCalibration.Factor();//dynamic
}

I can't take a snapshot of the calibration for the reference setter
since the data is dynamic. 

So I am not sure how to hold a reference to something so I can
discover the state of the internal entity (calibration) at runtime
from the mix design.

Mike

--- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@...> wrote:
>
> You're right, I'm probably not getting what your problem is. As I
> understand it:
> 
> // ...some method in a different aggregate...
> {
> MixDesign mixForCalc = (new
> RepositoryLocator(...)).getMixDesignRepository().findByID(1874);
> 
> Calibration calibrationForCalc =
mixForCalc.getCalibrationByCriteria(...);
> 
> ... use calibrationForCalc here for something ...
> calibrationForCalc = null; // drop the reference
> }
> 
> Are you referring to the problem of weak entity types in
> Entity-Relationship modeling? In other words, is Calibration's primary
> key is entirely dependent on MixDesign's primary key?
> 
> 
> --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> <nichols_mike_s@> wrote:
> >
> > I don't understand how this resolves maintaining references to
> > internal entities in a different aggregate root? 
> > Maybe I should clarify that I need to persist the 'which one' question
> > pertaining to the internal entities for consumption outside the
> > aggregate root...not just for a single operation.
> > 
> > 
> > --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@> wrote:
> > >
> > > The edict about aggregates isn't as restrictive as it sounds.
> > > 
> > > You generally can hold references to internal entities, as long as
> > > they are transient and don't last longer than one operation. Another
> > > technique I use is to allow only the aggregate root's repository to
> > > use the internal entity repository. The implication of this is that
> > > the references to internal entities is done via the aggregate root. 
> > > 
> > > Yet another technique is to return the internal entities as
immutable,
> > > if at all possible.
> > > 
> > > --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> > > <nichols_mike_s@> wrote:
> > > >
> > > > I have an entity 'Calibration' which is a variant entity under the
> > > > Aggregate 'MixDesign'. MixDesigns create calibrations and
> calibrations
> > > > are only valid as they represent a valuation based on mix design
> > > > properties. There is no such thing as a calibration without a mix
> > > design.
> > > > 
> > > > I have other objects outside the mix design aggregate boundary
which
> > > > need to know which calibration is being used for their
calculation,
> > > > but DDD dictates that no references to inner variants are held. 
> > > > 
> > > > I have considered moving Calibration to be its own aggregate but
> this
> > > > is awkward since a calibration really only exists as a valuation
> from
> > > > a mix design.
> > > > 
> > > > How have other people here dealt with this kind of
pseudo-aggregate
> > > > reference problem? I really don't want to implement a service to
> deal
> > > > with associations in the domain for something as simple as object
> > > > references.
> > > > Should I reference the calibration by some kind of business
key like
> > > > the Creation date (which is unique) or something?
> > > > thanks,
> > > > mike
> > > >
> > >
> >
>

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

headers

Paul Batum | 13 Aug 21:37

Re: Re: Getting references to internal entities from outside aggregate boundary

I am still new to DDD, but to me it sounds like Calibration needs to be an aggregate root. You mentioned that this makes you feel uncomfortable because "a calibration really only exists as a valuation from a mix design", but couldn't you make a similar argument, that "an order only exists as a transaction with a customer"? Regardless of this fact, Order is usually an aggregate root.

Paul Batum

On Wed, Aug 13, 2008 at 7:57 AM, nichols_mike_s <nichols_mike_s <at> yahoo.com> wrote:

Code would maybe help clarify further...

project.SetSpecMixDesign(MixDesign md){
mixDesign=md;
}
project.ApproveCalibrationForSpec(Calibration calibration) {
approvedCalibration = calibration;//but this violates root boundary
//here is where I need to associate the calibration outside its
aggregate
}

project.GetApprovedCalibrationFactor() {
return approvedCalibration.Factor();//dynamic
}

I can't take a snapshot of the calibration for the reference setter
since the data is dynamic.

So I am not sure how to hold a reference to something so I can
discover the state of the internal entity (calibration) at runtime
from the mix design.

Mike

--- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub <at> ...> wrote:
>
> You're right, I'm probably not getting what your problem is. As I
> understand it:
>
> // ...some method in a different aggregate...
> {
> MixDesign mixForCalc = (new
> RepositoryLocator(...)).getMixDesignRepository().findByID(1874);
>
> Calibration calibrationForCalc =
mixForCalc.getCalibrationByCriteria(...);
>
> ... use calibrationForCalc here for something ...
> calibrationForCalc = null; // drop the reference
> }
>
> Are you referring to the problem of weak entity types in
> Entity-Relationship modeling? In other words, is Calibration's primary
> key is entirely dependent on MixDesign's primary key?
>
>
> --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> <nichols_mike_s <at> > wrote:
> >
> > I don't understand how this resolves maintaining references to
> > internal entities in a different aggregate root?
> > Maybe I should clarify that I need to persist the 'which one' question
> > pertaining to the internal entities for consumption outside the
> > aggregate root...not just for a single operation.
> >
> >
> > --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub <at> > wrote:
> > >
> > > The edict about aggregates isn't as restrictive as it sounds.
> > >
> > > You generally can hold references to internal entities, as long as
> > > they are transient and don't last longer than one operation. Another
> > > technique I use is to allow only the aggregate root's repository to
> > > use the internal entity repository. The implication of this is that
> > > the references to internal entities is done via the aggregate root.
> > >
> > > Yet another technique is to return the internal entities as
immutable,
> > > if at all possible.
> > >
> > > --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> > > <nichols_mike_s <at> > wrote:
> > > >
> > > > I have an entity 'Calibration' which is a variant entity under the
> > > > Aggregate 'MixDesign'. MixDesigns create calibrations and
> calibrations
> > > > are only valid as they represent a valuation based on mix design
> > > > properties. There is no such thing as a calibration without a mix
> > > design.
> > > >
> > > > I have other objects outside the mix design aggregate boundary
which
> > > > need to know which calibration is being used for their
calculation,
> > > > but DDD dictates that no references to inner variants are held.
> > > >
> > > > I have considered moving Calibration to be its own aggregate but
> this
> > > > is awkward since a calibration really only exists as a valuation
> from
> > > > a mix design.
> > > >
> > > > How have other people here dealt with this kind of
pseudo-aggregate
> > > > reference problem? I really don't want to implement a service to
> deal
> > > > with associations in the domain for something as simple as object
> > > > references.
> > > > Should I reference the calibration by some kind of business
key like
> > > > the Creation date (which is unique) or something?
> > > > thanks,
> > > > mike
> > > >
> > >
> >
>

__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___

headers

moffdub | 14 Aug 00:50

Re: Getting references to internal entities from outside aggregate boundary

Maybe you can scrap ApproveCalibrationForSpec() and re-write
GetApprovedCalibrationFactor() like this:

project.GetApprovedCalibrationFactor()
{
    return mixDesign.getCalibrationByCriteria(...).Factor();
    // assuming you can add a getCalibrationByCriteria method
}

That way the reference to Calibration is held only for the life of
GetApprovedCalibrationFactor().

--- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
<nichols_mike_s@...> wrote:
>
> Code would maybe help clarify further...
> 
> project.SetSpecMixDesign(MixDesign md){
>  mixDesign=md;
> }
> project.ApproveCalibrationForSpec(Calibration calibration) {
>    approvedCalibration = calibration;//but this violates root boundary
>   //here is where I need to associate the calibration outside its
> aggregate
> }
> 
> project.GetApprovedCalibrationFactor() {
>   return   approvedCalibration.Factor();//dynamic
> }
> 
> I can't take a snapshot of the calibration for the reference setter
> since the data is dynamic. 
> 
> So I am not sure how to hold a reference to something so I can
> discover the state of the internal entity (calibration) at runtime
> from the mix design.
> 
> Mike
> 
> --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@> wrote:
> >
> > You're right, I'm probably not getting what your problem is. As I
> > understand it:
> > 
> > // ...some method in a different aggregate...
> > {
> > MixDesign mixForCalc = (new
> > RepositoryLocator(...)).getMixDesignRepository().findByID(1874);
> > 
> > Calibration calibrationForCalc =
> mixForCalc.getCalibrationByCriteria(...);
> > 
> > ... use calibrationForCalc here for something ...
> > calibrationForCalc = null; // drop the reference
> > }
> > 
> > Are you referring to the problem of weak entity types in
> > Entity-Relationship modeling? In other words, is Calibration's primary
> > key is entirely dependent on MixDesign's primary key?
> > 
> > 
> > --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> > <nichols_mike_s@> wrote:
> > >
> > > I don't understand how this resolves maintaining references to
> > > internal entities in a different aggregate root? 
> > > Maybe I should clarify that I need to persist the 'which one'
question
> > > pertaining to the internal entities for consumption outside the
> > > aggregate root...not just for a single operation.
> > > 
> > > 
> > > --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@>
wrote:
> > > >
> > > > The edict about aggregates isn't as restrictive as it sounds.
> > > > 
> > > > You generally can hold references to internal entities, as long as
> > > > they are transient and don't last longer than one operation.
Another
> > > > technique I use is to allow only the aggregate root's
repository to
> > > > use the internal entity repository. The implication of this is
that
> > > > the references to internal entities is done via the aggregate
root. 
> > > > 
> > > > Yet another technique is to return the internal entities as
> immutable,
> > > > if at all possible.
> > > > 
> > > > --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> > > > <nichols_mike_s@> wrote:
> > > > >
> > > > > I have an entity 'Calibration' which is a variant entity
under the
> > > > > Aggregate 'MixDesign'. MixDesigns create calibrations and
> > calibrations
> > > > > are only valid as they represent a valuation based on mix design
> > > > > properties. There is no such thing as a calibration without
a mix
> > > > design.
> > > > > 
> > > > > I have other objects outside the mix design aggregate boundary
> which
> > > > > need to know which calibration is being used for their
> calculation,
> > > > > but DDD dictates that no references to inner variants are held. 
> > > > > 
> > > > > I have considered moving Calibration to be its own aggregate but
> > this
> > > > > is awkward since a calibration really only exists as a valuation
> > from
> > > > > a mix design.
> > > > > 
> > > > > How have other people here dealt with this kind of
> pseudo-aggregate
> > > > > reference problem? I really don't want to implement a service to
> > deal
> > > > > with associations in the domain for something as simple as
object
> > > > > references.
> > > > > Should I reference the calibration by some kind of business
> key like
> > > > > the Creation date (which is unique) or something?
> > > > > thanks,
> > > > > mike
> > > > >
> > > >
> > >
> >
>

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

headers

nichols_mike_s | 14 Aug 19:53

Re: Getting references to internal entities from outside aggregate boundary

I had considered creating a criteria for the project to hold reference
to in just this way. The only thing that concerned me was the
brittleness. Thanks for your feedback.

--- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@...> wrote:
>
> Maybe you can scrap ApproveCalibrationForSpec() and re-write
> GetApprovedCalibrationFactor() like this:
> 
> project.GetApprovedCalibrationFactor()
> {
>     return mixDesign.getCalibrationByCriteria(...).Factor();
>     // assuming you can add a getCalibrationByCriteria method
> }
> 
> That way the reference to Calibration is held only for the life of
> GetApprovedCalibrationFactor().
> 
> --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> <nichols_mike_s@> wrote:
> >
> > Code would maybe help clarify further...
> > 
> > project.SetSpecMixDesign(MixDesign md){
> >  mixDesign=md;
> > }
> > project.ApproveCalibrationForSpec(Calibration calibration) {
> >    approvedCalibration = calibration;//but this violates root boundary
> >   //here is where I need to associate the calibration outside its
> > aggregate
> > }
> > 
> > project.GetApprovedCalibrationFactor() {
> >   return   approvedCalibration.Factor();//dynamic
> > }
> > 
> > I can't take a snapshot of the calibration for the reference setter
> > since the data is dynamic. 
> > 
> > So I am not sure how to hold a reference to something so I can
> > discover the state of the internal entity (calibration) at runtime
> > from the mix design.
> > 
> > Mike
> > 
> > --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@> wrote:
> > >
> > > You're right, I'm probably not getting what your problem is. As I
> > > understand it:
> > > 
> > > // ...some method in a different aggregate...
> > > {
> > > MixDesign mixForCalc = (new
> > > RepositoryLocator(...)).getMixDesignRepository().findByID(1874);
> > > 
> > > Calibration calibrationForCalc =
> > mixForCalc.getCalibrationByCriteria(...);
> > > 
> > > ... use calibrationForCalc here for something ...
> > > calibrationForCalc = null; // drop the reference
> > > }
> > > 
> > > Are you referring to the problem of weak entity types in
> > > Entity-Relationship modeling? In other words, is Calibration's
primary
> > > key is entirely dependent on MixDesign's primary key?
> > > 
> > > 
> > > --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> > > <nichols_mike_s@> wrote:
> > > >
> > > > I don't understand how this resolves maintaining references to
> > > > internal entities in a different aggregate root? 
> > > > Maybe I should clarify that I need to persist the 'which one'
> question
> > > > pertaining to the internal entities for consumption outside the
> > > > aggregate root...not just for a single operation.
> > > > 
> > > > 
> > > > --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@>
> wrote:
> > > > >
> > > > > The edict about aggregates isn't as restrictive as it sounds.
> > > > > 
> > > > > You generally can hold references to internal entities, as
long as
> > > > > they are transient and don't last longer than one operation.
> Another
> > > > > technique I use is to allow only the aggregate root's
> repository to
> > > > > use the internal entity repository. The implication of this is
> that
> > > > > the references to internal entities is done via the aggregate
> root. 
> > > > > 
> > > > > Yet another technique is to return the internal entities as
> > immutable,
> > > > > if at all possible.
> > > > > 
> > > > > --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> > > > > <nichols_mike_s@> wrote:
> > > > > >
> > > > > > I have an entity 'Calibration' which is a variant entity
> under the
> > > > > > Aggregate 'MixDesign'. MixDesigns create calibrations and
> > > calibrations
> > > > > > are only valid as they represent a valuation based on mix
design
> > > > > > properties. There is no such thing as a calibration without
> a mix
> > > > > design.
> > > > > > 
> > > > > > I have other objects outside the mix design aggregate boundary
> > which
> > > > > > need to know which calibration is being used for their
> > calculation,
> > > > > > but DDD dictates that no references to inner variants are
held. 
> > > > > > 
> > > > > > I have considered moving Calibration to be its own
aggregate but
> > > this
> > > > > > is awkward since a calibration really only exists as a
valuation
> > > from
> > > > > > a mix design.
> > > > > > 
> > > > > > How have other people here dealt with this kind of
> > pseudo-aggregate
> > > > > > reference problem? I really don't want to implement a
service to
> > > deal
> > > > > > with associations in the domain for something as simple as
> object
> > > > > > references.
> > > > > > Should I reference the calibration by some kind of business
> > key like
> > > > > > the Creation date (which is unique) or something?
> > > > > > thanks,
> > > > > > mike
> > > > > >
> > > > >
> > > >
> > >
> >
>

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

headers

Greg Young | 14 Aug 03:23

Re: Re: Getting references to internal entities from outside aggregate boundary

I think you actually want a

Calibration

and an

ApprovedCalibration ...

Let's just say for a moment that there is some business logic in
ApproveCalibrationForSpec() ... then you copy the object as you do ...
while you do this someone changes the Calibration in the other
aggregate root ... ummm ....

If you introduced the concept of an ApprovedCalibration (might just
inherit from Calibration and make it immutable etc) you would do
something like:

> project.ApproveCalibrationForSpec(Calibration calibration) {
> approvedCalibration = new ApprovedCalibration(calibration);
> }

You say that you can't do this because its "dynamic" but why would you
want an "Approved" calibration that you are probably running some sort
of validation on to be changed by another object?

If you really need it changed in this way then it is probably its own
aggregate with soft links from the other aggregates as opposed to a
direct reference.

Cheers,

Greg

On Tue, Aug 12, 2008 at 10:57 PM, nichols_mike_s
<nichols_mike_s <at> yahoo.com> wrote:
> Code would maybe help clarify further...
>
> project.SetSpecMixDesign(MixDesign md){
> mixDesign=md;
> }
> project.ApproveCalibrationForSpec(Calibration calibration) {
> approvedCalibration = calibration;//but this violates root boundary
> //here is where I need to associate the calibration outside its
> aggregate
> }
>
> project.GetApprovedCalibrationFactor() {
> return approvedCalibration.Factor();//dynamic
> }
>
> I can't take a snapshot of the calibration for the reference setter
> since the data is dynamic.
>
> So I am not sure how to hold a reference to something so I can
> discover the state of the internal entity (calibration) at runtime
> from the mix design.
>
> Mike
>
> --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@...> wrote:
>>
>> You're right, I'm probably not getting what your problem is. As I
>> understand it:
>>
>> // ...some method in a different aggregate...
>> {
>> MixDesign mixForCalc = (new
>> RepositoryLocator(...)).getMixDesignRepository().findByID(1874);
>>
>> Calibration calibrationForCalc =
> mixForCalc.getCalibrationByCriteria(...);
>>
>> ... use calibrationForCalc here for something ...
>> calibrationForCalc = null; // drop the reference
>> }
>>
>> Are you referring to the problem of weak entity types in
>> Entity-Relationship modeling? In other words, is Calibration's primary
>> key is entirely dependent on MixDesign's primary key?
>>
>>
>> --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
>> <nichols_mike_s@> wrote:
>> >
>> > I don't understand how this resolves maintaining references to
>> > internal entities in a different aggregate root?
>> > Maybe I should clarify that I need to persist the 'which one' question
>> > pertaining to the internal entities for consumption outside the
>> > aggregate root...not just for a single operation.
>> >
>> >
>> > --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@> wrote:
>> > >
>> > > The edict about aggregates isn't as restrictive as it sounds.
>> > >
>> > > You generally can hold references to internal entities, as long as
>> > > they are transient and don't last longer than one operation. Another
>> > > technique I use is to allow only the aggregate root's repository to
>> > > use the internal entity repository. The implication of this is that
>> > > the references to internal entities is done via the aggregate root.
>> > >
>> > > Yet another technique is to return the internal entities as
> immutable,
>> > > if at all possible.
>> > >
>> > > --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
>> > > <nichols_mike_s@> wrote:
>> > > >
>> > > > I have an entity 'Calibration' which is a variant entity under the
>> > > > Aggregate 'MixDesign'. MixDesigns create calibrations and
>> calibrations
>> > > > are only valid as they represent a valuation based on mix design
>> > > > properties. There is no such thing as a calibration without a mix
>> > > design.
>> > > >
>> > > > I have other objects outside the mix design aggregate boundary
> which
>> > > > need to know which calibration is being used for their
> calculation,
>> > > > but DDD dictates that no references to inner variants are held.
>> > > >
>> > > > I have considered moving Calibration to be its own aggregate but
>> this
>> > > > is awkward since a calibration really only exists as a valuation
>> from
>> > > > a mix design.
>> > > >
>> > > > How have other people here dealt with this kind of
> pseudo-aggregate
>> > > > reference problem? I really don't want to implement a service to
>> deal
>> > > > with associations in the domain for something as simple as object
>> > > > references.
>> > > > Should I reference the calibration by some kind of business
> key like
>> > > > the Creation date (which is unique) or something?
>> > > > thanks,
>> > > > mike
>> > > >
>> > >
>> >
>>
>
> 

--

-- 
It is the mark of an educated mind to be able to entertain a thought
without accepting it.

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

headers

nichols_mike_s | 14 Aug 20:00

Re: Getting references to internal entities from outside aggregate boundary

Thanks Greg
Calibration values can change after a project creates a calibration
snapshot like this so that would throw off our factor impacting
dependencies.
I appreciate your feedback.
mike

--- In domaindrivendesign <at> yahoogroups.com, "Greg Young"
<gregoryyoung1@...> wrote:
>
> I think you actually want a
> 
> Calibration
> 
> and an
> 
> ApprovedCalibration ...
> 
> Let's just say for a moment that there is some business logic in
> ApproveCalibrationForSpec() ... then you copy the object as you do ...
> while you do this someone changes the Calibration in the other
> aggregate root ... ummm ....
> 
> If you introduced the concept of an ApprovedCalibration (might just
> inherit from Calibration and make it immutable etc) you would do
> something like:
> 
> > project.ApproveCalibrationForSpec(Calibration calibration) {
> > approvedCalibration = new ApprovedCalibration(calibration);
> > }
> 
> You say that you can't do this because its "dynamic" but why would you
> want an "Approved" calibration that you are probably running some sort
> of validation on to be changed by another object?
> 
> If you really need it changed in this way then it is probably its own
> aggregate with soft links from the other aggregates as opposed to a
> direct reference.
> 
> Cheers,
> 
> Greg
> 
> 
> On Tue, Aug 12, 2008 at 10:57 PM, nichols_mike_s
> <nichols_mike_s@...> wrote:
> > Code would maybe help clarify further...
> >
> > project.SetSpecMixDesign(MixDesign md){
> > mixDesign=md;
> > }
> > project.ApproveCalibrationForSpec(Calibration calibration) {
> > approvedCalibration = calibration;//but this violates root boundary
> > //here is where I need to associate the calibration outside its
> > aggregate
> > }
> >
> > project.GetApprovedCalibrationFactor() {
> > return approvedCalibration.Factor();//dynamic
> > }
> >
> > I can't take a snapshot of the calibration for the reference setter
> > since the data is dynamic.
> >
> > So I am not sure how to hold a reference to something so I can
> > discover the state of the internal entity (calibration) at runtime
> > from the mix design.
> >
> > Mike
> >
> > --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@> wrote:
> >>
> >> You're right, I'm probably not getting what your problem is. As I
> >> understand it:
> >>
> >> // ...some method in a different aggregate...
> >> {
> >> MixDesign mixForCalc = (new
> >> RepositoryLocator(...)).getMixDesignRepository().findByID(1874);
> >>
> >> Calibration calibrationForCalc =
> > mixForCalc.getCalibrationByCriteria(...);
> >>
> >> ... use calibrationForCalc here for something ...
> >> calibrationForCalc = null; // drop the reference
> >> }
> >>
> >> Are you referring to the problem of weak entity types in
> >> Entity-Relationship modeling? In other words, is Calibration's
primary
> >> key is entirely dependent on MixDesign's primary key?
> >>
> >>
> >> --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> >> <nichols_mike_s@> wrote:
> >> >
> >> > I don't understand how this resolves maintaining references to
> >> > internal entities in a different aggregate root?
> >> > Maybe I should clarify that I need to persist the 'which one'
question
> >> > pertaining to the internal entities for consumption outside the
> >> > aggregate root...not just for a single operation.
> >> >
> >> >
> >> > --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@>
wrote:
> >> > >
> >> > > The edict about aggregates isn't as restrictive as it sounds.
> >> > >
> >> > > You generally can hold references to internal entities, as
long as
> >> > > they are transient and don't last longer than one operation.
Another
> >> > > technique I use is to allow only the aggregate root's
repository to
> >> > > use the internal entity repository. The implication of this
is that
> >> > > the references to internal entities is done via the aggregate
root.
> >> > >
> >> > > Yet another technique is to return the internal entities as
> > immutable,
> >> > > if at all possible.
> >> > >
> >> > > --- In domaindrivendesign <at> yahoogroups.com, "nichols_mike_s"
> >> > > <nichols_mike_s@> wrote:
> >> > > >
> >> > > > I have an entity 'Calibration' which is a variant entity
under the
> >> > > > Aggregate 'MixDesign'. MixDesigns create calibrations and
> >> calibrations
> >> > > > are only valid as they represent a valuation based on mix
design
> >> > > > properties. There is no such thing as a calibration without
a mix
> >> > > design.
> >> > > >
> >> > > > I have other objects outside the mix design aggregate boundary
> > which
> >> > > > need to know which calibration is being used for their
> > calculation,
> >> > > > but DDD dictates that no references to inner variants are held.
> >> > > >
> >> > > > I have considered moving Calibration to be its own
aggregate but
> >> this
> >> > > > is awkward since a calibration really only exists as a
valuation
> >> from
> >> > > > a mix design.
> >> > > >
> >> > > > How have other people here dealt with this kind of
> > pseudo-aggregate
> >> > > > reference problem? I really don't want to implement a
service to
> >> deal
> >> > > > with associations in the domain for something as simple as
object
> >> > > > references.
> >> > > > Should I reference the calibration by some kind of business
> > key like
> >> > > > the Creation date (which is unique) or something?
> >> > > > thanks,
> >> > > > mike
> >> > > >
> >> > >
> >> >
> >>
> >
> > 
> 
> 
> 
> -- 
> It is the mark of an educated mind to be able to entertain a thought
> without accepting it.
>

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