----- Original Message -----

From: Udi Dahan

To: domaindrivendesign@yahoogroups.com

Sent: Tuesday, November 24, 2009 7:22 AM

Subject: RE: [domaindrivendesign] Re: Complexity of validation-rules

 

> But what happens when domain objects interact with each other?

Objects in a domain model for a given bounded context are inherently coupled to each other.

In CQRS, the work the domain model does is always triggered by some command at the service layer, which is where inputs are validated.

In your previous example, there is no customer object that arrives in the command - at best, a customer ID.

In that case, either the customer would be the AR, or the ID itself would be passed into a method called on a different AR.

Hope that makes sense.

-- Udi Dahan

From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Jørn Wildt
Sent: Tuesday, November 24, 2009 12:20 AM
To: domaindrivendesign@yahoogroups.com
Subject: Re: [domaindrivendesign] Re: Complexity of validation-rules

 

> Bypassed? What's doing the bypassing?

I was sort of expecting you to answer like this :-) The service layer is
certainly a hard boundary for the "outside" world. But what happens when
domain objects interact with each other? They won't go through the service
layer but simply call each other's methods.

At least one of my postulates above must be wrong, I am quite confident that
you have everything worked out. The question is just what I am missing?

/Jørn

----- Original Message -----
From: Udi Dahan
To: domaindrivendesign@yahoogroups.com
Sent: Monday, November 23, 2009 9:45 PM
Subject: RE: [domaindrivendesign] Re: Complexity of validation-rules

> The initial issue was that Udi suggests to put these kinds of checks in
> the service layer. But if that can be bypassed and we don't want it in the
> domain where should it go then

Bypassed? What's doing the bypassing? When doing CQRS, there is no other use
for the domain than behind the service layer.

-- Udi Dahan

From: domaindrivendesign@yahoogroups.com
[mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Jorn Wildt
Sent: Monday, November 23, 2009 4:03 PM
To: domaindrivendesign@yahoogroups.com
Subject: [domaindrivendesign] Re: Complexity of validation-rules

--- In domaindrivendesign@yahoogroups.com, Nino Martincevic <don@...> wrote:
> > ... and it is these exceptions I am concerned about. You may have a
> > string field (backed by a database) which cannot exceed 100 chars, or
> > ...
> Aren't theses exactly requirements that *are* outside the domain?
> Because a database (persistence) rule is not a domain rule.

Absolutely agree - it has nothing to do with the domain.

> When my domain says this string can now be longer than 100 chars then it
> is a fact and the dba guys have to adjust that.
>
> The fact that a database throws an exception is actually not my (the
> domain's) problem, is it?

No, it is not, I certainly agree on this. But if the check is done in the
service layer then we can bypass it. So I was trying to put it in some
shared place we always have to go through.

The initial issue was that Udi suggests to put these kinds of checks in the
service layer. But if that can be bypassed and we don't want it in the
domain where should it go then ...

Oh, well, I guess the most appropriate place is in the database layer. This
is "below" the domain and will always be called. We just need to make sure
errors in the database can be handled gracefully in the UI.

But I still wonder why Udi wants it in the service layer ...

Thanks, Jørn

I aggree from the begining on this.

My point is that I try to keep only things that are part of the state in
entities.
Once again, you can choose not to do that. Up to you.

cheers,

jeremie / thinkbeforecoding


--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> Generally,
>
> Yes I'm not a big fan of DI either for the reason you state, yet it is an
option for complex configuration. But this is orthogonal to DI or not to DI
domain services or any other kind of strategy.
>
> Cheers,
>
> Nuno
>

Generally,

Yes I'm not a big fan of DI either for the reason you state, yet it is an option
for complex configuration. But this is orthogonal to DI or not to DI domain
services or any other kind of strategy.

Cheers,

Nuno

Of course you would check it before sending the command.

You can verify there is no conflict it when putting the denormalization in the
table that will use this key for uniqueness.

I repeat the preconditions of these decisions (because it seems it doesn't apply
to you) :
* You use surrogate keys, so you don't use this uniqueness at the repository
level
* you always get the entities from the repository with their surrogate key
* The uniqueness is requiered for lookup purpose

if any of the following doesn't apply, you should find a AR to enforce the
uniqueness, or if you use domain keys in your repository, the repository should
enforce uniqueness.

jeremie / thinkbeforecoding

--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> In wish way it is a query concern?
>
> When in the execution of the query such constraint is enforced?
>
> Cheers
>
> Nuno
>
> On 2009/11/23, at 22:24, Jérémie <Jeremie.Chassaing@...>
> wrote:
>
> > I recognize the importance of the invariant, but I want to put it
> > where it belongs.
> > Most often this invariant is a query concern.
> > When it's not, do what's appropiate in the repository or in another
> > aggregate root.
> >
> > cheers,
> >
> > jeremie / thinkbeforecoding
> >
> > --- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@>
> > wrote:
> > >
> > > Jeremie,
> > >
> > > I'm not taking any code shortcut. That is not the point!
> > >
> > > It incredible that people understand the concept of invariants
> > within an AR and fail to recognize invariant across a simple
> > collection like object such as a Repository.
> > >
> > > The problem for some DDD people is that Repository is not indeed a
> > Aggregate as defined by Evans, so it seams that invariants go out
> > the window looking for its care takers. The question is why?
> > >
> > > My point is that if you don't drop those invariants the care taker
> > is the Repository, yet the implementation might be outside the
> > domain (much like any other business rule).
> > >
> > > Now to drop or not to drop that is the question. Instead of
> > relying on a mechanism to decide what can be consistent and what can
> > eventually be consistent, if we are going to drop invariants we need
> > to:
> > >
> > > - ask why in context and what are the benefits 1)
> > > - then we evaluate the business risks of dropping them 2) (there
> > are already significant technical risks, make no mistake!)
> > > - then after we decide we should devise strategies that may
> > include business processes to to replace the invariants with with
> > other business rules that are less stringent 3)
> > >
> > > This is totally different from being eventual consistent. We
> > collectively made a conscious technical and business decision to
> > drop a business rule in favor of scalability and increased business
> > revenue per second or whatever. We DROPPED THE RULE and replace by
> > other ones period! We don't rely on a pattern to make the decision
> > for us.
> > >
> > > Best of luck.
> > >
> > > Cheers,
> > >
> > > Nuno
> > > PS: http://plato.stanford.edu/entries/truth-axiomatic/#1.1
> > >
> >
> >
>

DI is very convenient to wire services together. That why I use it.

Putting all then configuration and data in the container has a smell of :
when all you have is a hammer...

cheers,

jeremie / thinkbeforecoding

--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> Hi Jer,
>
> "I never liked the use of DI to inject configuration or data, it
> usualy lead to hard to discover application configuration. But that's
> surely a personal choice."
>
> This seams to be a reasonable reason not to use DI.
>
> Cheers,
>
> Nuno
>
> On 2009/11/23, at 22:36, Jérémie <Jeremie.Chassaing@...>
> wrote:
>
> > I never liked the use of DI to inject configuration or data, it
> > usualy lead to hard to discover application configuration. But
> > that's surely a personal choice.
>

 

I recognize the importance of the invariant, but I want to put it where it belongs.
Most often this invariant is a query concern.
When it's not, do what's appropiate in the repository or in another aggregate root.

cheers,

jeremie / thinkbeforecoding

--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> Jeremie,
>
> I'm not taking any code shortcut. That is not the point!
>
> It incredible that people understand the concept of invariants within an AR and fail to recognize invariant across a simple collection like object such as a Repository.
>
> The problem for some DDD people is that Repository is not indeed a Aggregate as defined by Evans, so it seams that invariants go out the window looking for its care takers. The question is why?
>
> My point is that if you don't drop those invariants the care taker is the Repository, yet the implementation might be outside the domain (much like any other business rule).
>
> Now to drop or not to drop that is the question. Instead of relying on a mechanism to decide what can be consistent and what can eventually be consistent, if we are going to drop invariants we need to:
>
> - ask why in context and what are the benefits 1)
> - then we evaluate the business risks of dropping them 2) (there are already significant technical risks, make no mistake!)
> - then after we decide we should devise strategies that may include business processes to to replace the invariants with with other business rules that are less stringent 3)
>
> This is totally different from being eventual consistent. We collectively made a conscious technical and business decision to drop a business rule in favor of scalability and increased business revenue per second or whatever. We DROPPED THE RULE and replace by other ones period! We don't rely on a pattern to make the decision for us.
>
> Best of luck.
>
> Cheers,
>
> Nuno
> PS: http://plato.stanford.edu/entries/truth-axiomatic/#1.1
>

Hi Jer,

"I never liked the use of DI to inject configuration or data, it
usualy lead to hard to discover application configuration. But that's
surely a personal choice."

This seams to be a reasonable reason not to use DI.

Cheers,

Nuno

On 2009/11/23, at 22:36, Jérémie <Jeremie.Chassaing@...>
wrote:

> I never liked the use of DI to inject configuration or data, it
> usualy lead to hard to discover application configuration. But
> that's surely a personal choice.

Objects in a domain model for a given bounded context are inherently coupled to each other.

> No the Strategy IMHO can be used with double dispatch.
> A particular case of the strategy pattern is the Specification
> pattern. You are right that all of them have to do with polymorphism

I did not say that strategy could not be used with double dispatch.
But it seems also ok to use strategy to change behavior inside an entity.

I never liked the use of DI to inject configuration or data, it usualy lead to
hard to discover application configuration. But that's surely a personal choice.

But hey, design a question of choice. I give the reason for the choice I would
make. If you don't like it, it's up to you.
There will never be One Unique Way to do things.
I just try to give a consistent view of my design choices.
So don't feel offended,

cheers,


jeremie / thinkbeforecoding



--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> Jeremie,
>
> The question I ask is why such preference considering how traditionally double
dispatch and strategy patterns are used? Just note that Repositories are not
domain services.
>
> The reasons you presented are and I quote:
>
> > To sum up the reason, services are not part of the state
> > of entities so they should not be stored in fields.
> >
>
> Yet you also state:
>
> > If you reread my post, you'll see that i'm not against any type of
injection. Injecting strategies in entities is ok.
> >
> > The distinction is that strategy is a construct at the 'object model' level.
It's a OO practice to split code on classes rather that switch.
> > It can get a meaning at the domain level, but it remains a oo practice. It's
a way to make the *entity's behavior* versatil.
> > A reference to a strategy in an entity is ok, since the behavior is part of
the entity.
>
> No the Strategy IMHO can be used with double dispatch.  A particular case of
the strategy pattern is the Specification pattern. You are right that all of
them have to do with polymorphism. Here is the distinction IMHO:
>
> 1) Strategy Pattern: This used when we need to change an object behavior
within the scope of one or several operation at run time, per argument or
configuration.
>
> 2) Specification/Policy Pattern: Used when the output of the behavior is true
of false when applied to the target object state. An interesting
>
> 3) Double dispatch: Its a way to inject behaviors in operations when behaviors
change according to the type of arguments (type of collaborator in SOM). Double
dispatch is ideal in cases where the same operation behavior changes often and
in some way unpredictably according to its arguments. There are many examples on
the net from collision detection to drag and drop behaviors. These are domain
whose object behavior are highly dynamic and dependent on collaborator types.
>
> 4) DI: A way to inject configurable operation behaviors into an object. It can
inject not only behaviors but also state, so not only can inject strategies and
specification but also parameterized and so on. Of course it can do far more
then this up to a complete object graph, yet in my world this neither common or
advisable. I would use in systems that whose needs for dynamically changing
behavior are next to non (static configuration).
>
> 5) Service Locator: A way to inject behaviors by locating some object based on
a static specification. Not has sophisticated as DI but yet more light weight
(it can be easily implemented).
>
> Usually a IOC framework provided features for both 4) and 5). 3) is trivial.
>
> This is superficially my view over this, but I do take has central the
dynamics of the domain model to make a choice. Yet you argue that we should not
inject domain services without look at the domain dynamics, instead we should
always use double dispatch (I think Greg argues the same thing). I must say that
neither option IMHO has to do with domain anemia as far as I'm concerned so that
is not my concern at all.
>
> Cheers,
>
> Nuno
>

I recognize the importance of the invariant, but I want to put it where it
belongs.
Most often this invariant is a query concern.
When it's not, do what's appropiate in the repository or in another aggregate
root.

cheers,

jeremie / thinkbeforecoding



--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> Jeremie,
>
> I'm not taking any code shortcut. That is not the point!
>
> It incredible that people understand the concept of invariants within an AR
and fail to recognize invariant across a simple collection like object such as a
Repository.
>
> The problem for some DDD people is that Repository is not indeed a Aggregate
as defined by Evans, so it seams that invariants go out the window looking for
its care takers. The question is why?
>
> My point is that if you don't drop those invariants the care taker is the
Repository, yet the implementation might be outside the domain (much like any
other business rule).
>
> Now to drop or not to drop that is the question. Instead of relying on a
mechanism to decide what can be consistent and what can eventually be
consistent, if we are going to drop invariants we need to:
>
> - ask why in context and what are the benefits 1)
> - then we evaluate the business risks of dropping them 2) (there are already
significant technical risks, make no mistake!)
> - then after we decide we should devise strategies that may include business
processes to to replace the invariants with with other business rules that are
less stringent 3)
>
> This is totally different from being eventual consistent. We collectively made
a conscious technical and business decision to drop a business rule in favor of
scalability and increased business revenue per second or whatever. We DROPPED
THE RULE and replace by other ones period! We don't rely on a pattern to make
the decision for us.
>
> Best of luck.
>
> Cheers,
>
> Nuno
> PS: http://plato.stanford.edu/entries/truth-axiomatic/#1.1
>

> Bypassed? What's doing the bypassing?

I was sort of expecting you to answer like this :-) The service layer is
certainly a hard boundary for the "outside" world. But what happens when
domain objects interact with each other? They won't go through the service
layer but simply call each other's methods.

At least one of my postulates above must be wrong, I am quite confident that
you have everything worked out. The question is just what I am missing?

/Jørn

----- Original Message -----
From: Udi Dahan
To: domaindrivendesign@yahoogroups.com
Sent: Monday, November 23, 2009 9:45 PM
Subject: RE: [domaindrivendesign] Re: Complexity of validation-rules



> The initial issue was that Udi suggests to put these kinds of checks in
> the service layer. But if that can be bypassed and we don't want it in the
> domain where should it go then

Bypassed? What's doing the bypassing? When doing CQRS, there is no other use
for the domain than behind the service layer.

-- Udi Dahan

From: domaindrivendesign@yahoogroups.com
[mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Jorn Wildt
Sent: Monday, November 23, 2009 4:03 PM
To: domaindrivendesign@yahoogroups.com
Subject: [domaindrivendesign] Re: Complexity of validation-rules


--- In domaindrivendesign@yahoogroups.com, Nino Martincevic <don@...> wrote:
> > ... and it is these exceptions I am concerned about. You may have a
> > string field (backed by a database) which cannot exceed 100 chars, or
> > ...
> Aren't theses exactly requirements that *are* outside the domain?
> Because a database (persistence) rule is not a domain rule.

Absolutely agree - it has nothing to do with the domain.

> When my domain says this string can now be longer than 100 chars then it
> is a fact and the dba guys have to adjust that.
>
> The fact that a database throws an exception is actually not my (the
> domain's) problem, is it?

No, it is not, I certainly agree on this. But if the check is done in the
service layer then we can bypass it. So I was trying to put it in some
shared place we always have to go through.

The initial issue was that Udi suggests to put these kinds of checks in the
service layer. But if that can be bypassed and we don't want it in the
domain where should it go then ...

Oh, well, I guess the most appropriate place is in the database layer. This
is "below" the domain and will always be called. We just need to make sure
errors in the database can be handled gracefully in the UI.

But I still wonder why Udi wants it in the service layer ...

Thanks, Jørn

----- Original Message -----

From: Nuno Lopes

To: domaindrivendesign@yahoogroups.com

Sent: Monday, November 23, 2009 5:10 PM

Subject: Re: [domaindrivendesign] Re: Complexity of validation-rules

 

Oh,

Ok. I understand now.

In domain terms we actually don't want any restrictions on the length: why should anyone not be allowed to be called some exceptionally long name? 

That is a design only constraint indeed. Nevertheless the subject is a domain object as such the rule IMHO should be kickoff by the object. We have a set of standard value objects such as Name, InsurancePolicyNumber etc etc. Each of these values implement those constraints.

For instance:

PersonName name = new PersonName(".......................") // exceptionally long name

Would trigger a business exception if the name is over say 255.

This allow us to set some standards across BC over common kinds of business value objects.

Not null constraints are usually within the scope of required value constraints. Their scope can be the class, in this case is a class invariant, or a method. If it is a class invariant RDBMS gives us some help (NOT NULLS). If the scope is a method its implementation is trivial within a domain method as exemplified.

The reason why we want to do this is because we believe that domain objects should have a set of stable rules across databases and user interfaces. In a UI FORM the size of the user can be 200 in another 100, we don't care as long it complies with the domain limits set by design. The same goes for the database.

In sum. domain rules and some design rules whose subject are domain objects span out the domain m odel not the other way around. The domain model serves has the business foundation around which all other layers need to comply with (standards). If some UI require required a different length for the say the PersonName, either we change the standard or we create a specific type of Name for the domain object in question. Actually we goes even further. 

For trivial design rules relying on size or structure, where simple upper and minor bounds can be used (regexed or whatever) we configure them in XML files (Spring.NET IoC):

PersonName name = VOF.Create<PersonName>(....)

EmailAddress email = VOF.Create<EmailAddress>(....)

InsurancePolicyNumber number = VOF.Create<InsurancePolicyNumber>(....)

The nice thing is that these configurations can be shared across multiple layers (Domain Layer, Service Layer, UI Layer, Data base Layer etc)

Cheers,

Nuno

Hey, not entirely sure if it's appropriate to post here – i looked for a faq for
some policy, but i'll word my request informally. My company in Ottawa is
looking for top-shelf DDD practitioners for a fairly cool project. I can say
that we are guided by some of the best authorities in the DDD field. If you'd
like more info pls feel free to contact me.
Steph.
sswierenga3@...

But the shortcut you are taking to write less code doesn't prove that the
repository *should* be responsible for testing unicity when creating/modifying
entities.

in a cqrs scenario I would not do that anyway.

jeremie / thinkbeforecoding

--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> > but the question is about CQS/CQRS,
> > and in this case, your repository will provide only on one way to get the
entity, get it by Id.
> >
>
> Hi Jer,
>
> Taking what you say as the reference model to use the Repository in a CQRS
design, instead of discussing this stuff in abstract lets try this.
>
> Imagine an Entity called User with two properties Username, Password and a
method named Login. The user fills in the username and password, press the
button Login. Upon pressing the button Login a LoginUserCmd is generated with a
username and password by the server (or client). The handler of the command
would do:
>
> handler
> // transaction start
> Guid userId = SomeDomainService.GetUserIDByUsername(usermame); // Probably
querying the reporting system.
> User u = AllUsers.GetByUsername(userId);
> u.Login(cmd.Password);
> /// transaction end
>
> I find this second solution a bit cumbersome IMHO. You could also have
application layer in the UI query for the Guid, IMHO even worst.
>
> On the other hand if the repository returns ARs using other keys (candidate
keys, more natural keys).
>
> handler
> // transaction start
> User u = AllUsers.GetByUsername(cmd.Username);
> u.Login(cmd.Password);
> /// transaction end
>
> Better IMHO as it looks more "natural".
>
> Now you may be constrained by the ability of the machine supporting the
repository to return ARs based on more then one type of Key but that problem is
not within the scope of CQRS IMHO.
>
> Cheers,
>
> Nuno
> PS: I understand that the common case would be the through the use case some
data is already in the client side (say the output of a query). In these cases
the Guid of the Entity is already provided by a query so any transaction could
get the object by Guid. As I have shown this is not necessarily the case for all
domains.
>

--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
> > Aren't theses exactly requirements that *are* outside the domain?
> > Because a database (persistence) rule is not a domain rule.
> > When my domain says this string can now be longer than 100 chars then it
> > is a fact and the dba guys have to adjust that.
> I don't quite understand this sentence. You tell that the domain says
something that you conclude that that something is not part of the domain
because the rule it ends up being implemented in the database?

Things got a bit mixed here I can see that. In my view it is not a domain
requirement - the string length requirement is usually an arbitrary value chosen
in the database layer. At least I have never met any customer requirements for
string length. Usualy they just want "a field to store the name of X" and then
it's up to us to decide on something usefull.

In domain terms we actually don't want any restrictions on the length: why
should anyone not be allowed to be called some exceptionally long name? But
traditionally we save those values in varchar fields that have a restriction on
the length. That's why I argue that string length is a DB restriction.

Hopefully this clarifies it a bit.

/Jørn

but the question is about CQS/CQRS,
and in this case, your repository will provide only on one way to get the entity, get it by Id.

--- In domaindrivendesign@yahoogroups.com, Nino Martincevic <don@...> wrote:
> > ... and it is these exceptions I am concerned about. You may have a
> > string field (backed by a database) which cannot exceed 100 chars, or  ...
> Aren't theses exactly requirements that *are* outside the domain?
> Because a database (persistence) rule is not a domain rule.

Absolutely agree - it has nothing to do with the domain.

> When my domain says this string can now be longer than 100 chars then it
> is a fact and the dba guys have to adjust that.
>
> The fact that a database throws an exception is actually not my (the
> domain's) problem, is it?

No, it is not, I certainly agree on this. But if the check is done in the
service layer then we can bypass it. So I was trying to put it in some shared
place we always have to go through.

The initial issue was that Udi suggests to put these kinds of checks in the
service layer. But if that can be bypassed and we don't want it in the domain
where should it go then ...

Oh, well, I guess the most appropriate place is in the database layer. This is
"below" the domain and will always be called. We just need to make sure errors
in the database can be handled gracefully in the UI.

But I still wonder why Udi wants it in the service layer ...

Thanks, Jørn

Jorn Wildt wrote:
> ... and it is these exceptions I am concerned about. You may have a
> string field (backed by a database) which cannot exceed 100 chars, or
> you can have not-null requirements - and I bet there are more. These are
> *hard* requirements, meaning, it will never make sense to ignore them
> (since the database will throw an exception at you).
> So, when Udi argues that exactly these kinds of checks should be done
> outside the domain, I think we may run into trouble.

Aren't theses exactly requirements that *are* outside the domain?
Because a database (persistence) rule is not a domain rule.
When my domain says this string can now be longer than 100 chars then it
is a fact and the dba guys have to adjust that.

The fact that a database throws an exception is actually not my (the
domain's) problem, is it?

Cheers

Ok,
but the question is about CQS/CQRS,
and in this case, your repository will provide only on one way to get the
entity, get it by Id.

I would use a surrogate Id (a Guid) for that (of course I would have referential
identity from this id). And find it from domain lookup identities in the query
BC.

So no need to know this lookup key in the domain itself and to check the unicity
in the domain.

cheers,

jeremie / thinkbeforecoding



--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> Hi Jeremie,
>
> I don't know what you mean by lookup constraints. A lookup is a lookup. It can
return one object or several objects.
>
> In a given architecture wether we recognize identity constraints as domain
logic or not is irrelevant. If the Entity is part of the UL then they its
logical governance is domain logic, meaning that two entities with the same Key
are necessarily the same (So it not about lookups, its about
identity!!!!!!!!!!!!).
>
> Customer A = Customers.Get<Customer>(1);
> Customer B = Customers.Get<Customer>(1);
>
> Not only their IDs are equal, both A and B should reference the same object in
the same session or use case!!!! Since Customers is a domain concept it should
enforce such rules. If it was about lookups and query only then it could as well
return distinct objects with the same ID as usual.
>
> Indeed, if I'm not mistaken NHibernate within a session, Load would return two
equal references. Meaning accessing the object through A or B bounds to the same
thing.
>
> > Before being the one called Nuno, you are you. Even with no name.
> > I can call you Nuno, or something else (what are your nickname ?), but you
are still yourself.
>
> I'm fine with Guids, nevertheless I would encapsulate its generation either in
the Repository, and generate it upon adding the entity (the repository is part
of the domain, especially its collection like personality of AllCustomers,
AllUsers etc). You where probably advised to use Guids is because you need at
least the concept of Entity and identity to be secure and consistent upon adding
to the repository while not going the reporting side to validate. The reasons
behind it are obvious but you may argue them if you will within the scope of
CQRS.
>
> There are plenty of examples where unique constraints are part of domain
logic. For instance "no two registered customers can have the identical fiscal
number". "No two user can have the identical username" etc etc. We can discuss
these if you want but, I think that the Repository as a domain concept needs
consistent too.
>
> Nuno
>