Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

domaindrivendesign · Domain-Driven Design

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 4073
  • Category: Software
  • Founded: Sep 27, 2002
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Hear how Yahoo! Groups has changed the lives of others. Take me there.

Messages

Advanced
Messages Help
Messages 16715 - 16744 of 24071   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#16715 From: "stuart_faircloth" <stuart_faircloth@...>
Date: Thu Dec 24, 2009 7:05 pm
Subject: DTO objects in the domain
stuart_fairc...
Send Email Send Email
 
Hi,

My architecture is very simple. We have an entry point (service) into the system
which receives a DTO:

interface XXXService {
     void provideXXXFunctionality(XXXDTO dto);
}

These DTOs are then used to update domain objects. The DTO is complex and can
update many objects under an aggregate root. How is the updating of the domain
object best achieved?

1. I could add a method to the domain object and for each child object from the
root pass the DTO and have the object update itself:

class Domain {
   public void updateForXXX(XXXDTO dto);
}

But ideally I would like to keep the DTO out of the domain.

2. I could create a command to wrap the DTO but IMHO this removes the business
logic from the domain to the command and the functionality could be implemented
in the XXXService.provideXXXFunctionality method

3. Visitor pattern? Same drawbacks as the command pattern

#16716 From: "vvernon_shiftmethod" <vvernon@...>
Date: Sat Dec 26, 2009 11:23 pm
Subject: Re: DTO objects in the domain
vvernon_shif...
Send Email Send Email
 
Stuart,

I have a few thoughts on this.

> 1. I could add a method to the domain object and for each
> child object from the root pass the DTO and have the object
> update itself:

The only things that belong in your domain are terms from you UL. Also DTOs are
not domain objects. They are anemic objects that help bridge physical tiers in
separate processes. You could consider making your application layer service
methods receive serialized domain command objects instead. But if you are tied
to DTOs in the application layer, at a minimum you need to translate DTOs into
domain objects (see below).

> 2. I could create a command to wrap the DTO but IMHO this
> removes the business logic from the domain to the command
> and the functionality could be implemented in the
> XXXService.provideXXXFunctionality method

If you create commands, don't make them DTO wrappers. Also, commands don't have
to implement the mutation behavior on the aggregates. More often, IMO, a command
tells the aggregate what to do and with what, but doesn't do the command.

> 3. Visitor pattern? Same drawbacks as the command pattern

Well, I think the behavior is better if implemented in the aggregate. But it
might depend on the level of complexity.

All the above considered, I wonder if your application service methods are
revealing domain responsibilities. Remember that Domain Services are meant to
deal with domain behavior that doesn't fit or belong on any one domain object
(aggregate, entity, value, whatever). Rather the Domain Service orchestrates
behaviors across multiple domain objects. So as your application service
requests arrive, consider translating the DTOs into domain objects of some kind,
either commands or value objects. Then invoke a Domain Service method, which as
a receiver might be named closely to the application service sender, passing the
translated parameters (command or value objects). That Domain Service would use
Repositories to find aggregates that overlap in the use case / user story, and
invoke command methods on those aggregates, passing the applicable parts of the
parameter domain objects (commands or value objects). That will help correctly
keep your application services thin and retain your business logic only in the
core domain model.

Vaughn



--- In domaindrivendesign@yahoogroups.com, "stuart_faircloth"
<stuart_faircloth@...> wrote:
>
> Hi,
>
> My architecture is very simple. We have an entry point (service) into the
system which receives a DTO:
>
> interface XXXService {
>     void provideXXXFunctionality(XXXDTO dto);
> }
>
> These DTOs are then used to update domain objects. The DTO is complex and can
update many objects under an aggregate root. How is the updating of the domain
object best achieved?
>
> 1. I could add a method to the domain object and for each child object from
the root pass the DTO and have the object update itself:
>
> class Domain {
>   public void updateForXXX(XXXDTO dto);
> }
>
> But ideally I would like to keep the DTO out of the domain.
>
> 2. I could create a command to wrap the DTO but IMHO this removes the business
logic from the domain to the command and the functionality could be implemented
in the XXXService.provideXXXFunctionality method
>
> 3. Visitor pattern? Same drawbacks as the command pattern
>

#16717 From: Stefano Ricciardi <stefano.ricciardi@...>
Date: Mon Dec 28, 2009 2:28 pm
Subject: Entity, Repositories and Lazy Loading
sterioma
Send Email Send Email
 
Hi,

I have a rather peculiar domain where one of the entities models a
taxonomy of properties for a particular business object.
Oversimplifying, properties might have a first classification like
"numeric", "literal" and "date-related". Within each category, further
categories may be present thus creating a property tree.

The UI will show the user a navigation tree (much like an explorer of
a file system) to navigate through properties according to the
taxonomy.

I am modelling the property tree with an entity like the following:

class PropertyTreeNode
{
   public PropertyDescriptor Descriptor { get; private set; }  // this
contains metadata describing a property
   public bool HasChildren() { //... }
   public IEnumerable<PropertyTreeNode> GetChildren() { // .... }

    // follows constructor and private methods...
}

One of the problems I will be facing is that a single node can
potentially contain a *big*list of children. I would like to be able
to lazy load a node's children only when requested (e.g. because the
user wants to explore some part of a tree), without loading into
memory the overall tree at once.

However, I am not quite sure how to achieve this. As far as I
understand, domain model classes shouldn't refer to the repository or
any other infrastructure service. So, how can the domain model be
hydrated in a lazy way in a situation like this?

Thank you,
  Stefano

#16718 From: Gustavo Rocha <gustavohrocha@...>
Date: Mon Dec 28, 2009 5:38 pm
Subject: Re: Entity, Repositories and Lazy Loading
gh_rocha
Send Email Send Email
 
IMHO, we try to avoid that domain classes refer to the repository but it´s not forbidden.

By the way, the repository abstraction is part of the domain. The implementation will touch the infra but the repository is part of domain.

This will not anser completely your question but is very important than we remember the repository concept in DDD.

[]
Gustavo Rocha

PS: Sorry for the poor english


2009/12/28 Stefano Ricciardi <stefano.ricciardi@...>
 

Hi,

I have a rather peculiar domain where one of the entities models a
taxonomy of properties for a particular business object.
Oversimplifying, properties might have a first classification like
"numeric", "literal" and "date-related". Within each category, further
categories may be present thus creating a property tree.

The UI will show the user a navigation tree (much like an explorer of
a file system) to navigate through properties according to the
taxonomy.

I am modelling the property tree with an entity like the following:

class PropertyTreeNode
{
   public PropertyDescriptor Descriptor { get; private set; } // this
contains metadata describing a property
   public bool HasChildren() { //... }
   public IEnumerable<PropertyTreeNode> GetChildren() { // .... }

// follows constructor and private methods...
}

One of the problems I will be facing is that a single node can
potentially contain a *big*list of children. I would like to be able
to lazy load a node's children only when requested (e.g. because the
user wants to explore some part of a tree), without loading into
memory the overall tree at once.

However, I am not quite sure how to achieve this. As far as I
understand, domain model classes shouldn't refer to the repository or
any other infrastructure service. So, how can the domain model be
hydrated in a lazy way in a situation like this?

Thank you,
Stefano



#16719 From: "eben_roux" <eben.roux@...>
Date: Tue Dec 29, 2009 8:25 am
Subject: Re: Entity, Repositories and Lazy Loading
eben_roux
Send Email Send Email
 
Hello Stefano,

I have a vaguely similar structure on my current project.

You shouldn't think about your domain model in terms of your UI.  The domain
model should do what it does and be structured to perform that task.

Next you probably need some clever UI architecture to load the tree view nodes
when required.  For this you could query your data directly.   There is
absolutely no need to come close to your domain objects for this.  So your
lazy-load issue goes away --- I am no fan of lazy-load.

The other thing to keep in mind is that it is not necessary for each node in the
tree view to work in the same way.  By default a node could populate it's
children, but when faced with masses of data it may be more appropriate to
present your users with a search form and from there they can select the items
to add to the tree view for manipulation.

Regards,
Eben

--- In domaindrivendesign@yahoogroups.com, Stefano Ricciardi
<stefano.ricciardi@...> wrote:
>
> Hi,
>
> I have a rather peculiar domain where one of the entities models a
> taxonomy of properties for a particular business object.
> Oversimplifying, properties might have a first classification like
> "numeric", "literal" and "date-related". Within each category, further
> categories may be present thus creating a property tree.
>
> The UI will show the user a navigation tree (much like an explorer of
> a file system) to navigate through properties according to the
> taxonomy.
>
> I am modelling the property tree with an entity like the following:
>
> class PropertyTreeNode
> {
>    public PropertyDescriptor Descriptor { get; private set; }  // this
> contains metadata describing a property
>    public bool HasChildren() { //... }
>    public IEnumerable<PropertyTreeNode> GetChildren() { // .... }
>
>    // follows constructor and private methods...
> }
>
> One of the problems I will be facing is that a single node can
> potentially contain a *big*list of children. I would like to be able
> to lazy load a node's children only when requested (e.g. because the
> user wants to explore some part of a tree), without loading into
> memory the overall tree at once.
>
> However, I am not quite sure how to achieve this. As far as I
> understand, domain model classes shouldn't refer to the repository or
> any other infrastructure service. So, how can the domain model be
> hydrated in a lazy way in a situation like this?
>
> Thank you,
>  Stefano
>

#16720 From: Stefano Ricciardi <stefano.ricciardi@...>
Date: Tue Dec 29, 2009 11:18 am
Subject: Re: Re: Entity, Repositories and Lazy Loading
sterioma
Send Email Send Email
 
Hi Eben,

thank you for your reply. I am just getting my feet wet with DDD and
appreciate your hints. See my comments below.

On Tue, Dec 29, 2009 at 9:25 AM, eben_roux <eben.roux@...> wrote:
>
> You shouldn't think about your domain model in terms of your UI. The domain
model should do what it does and be structured to perform that task.

My domain model in this case is basically a group of business objects
(that can be of different nature (in a financial context it might be
for example an asset, a portfolio, a customer, etc...)) and a set of
dynamic properties that might be defined on those business objects.
With dynamic here I mean that those properties are not static
attributes of the objects but are "attached" to each object with a
"link" in the database.

Those are the 2 entities that I am dealing with.

The main use case is to allow the user to pick a business object type
(say a bond), browse through its properties (dynamically loaded from
the DB) and from there filter business objects based on the *values*
of one or more property (say, overall value, currency, etc..).


> Next you probably need some clever UI architecture to load the tree view nodes
when required. For this you could query your data directly. There is absolutely
no need to come close to your domain objects for this. So your lazy-load issue
goes away --- I am no fan of lazy-load.

What do you mean with "query your data directly"? Are you saying the
application infrastructure should directly access the repository and,
given a node in the tree, fetch its children? Isn't this the road
toward an "anemic" domain? To me, the fact that a property belongs to
a certain logical "tree" is intrinsic to the domain model. In fact
when talking with the business experts, the explicitly mention this
kind of taxonomy. Or am I just confusing the navigation aspect for a
domain model issue?


> The other thing to keep in mind is that it is not necessary for each node in
the tree view to work in the same way. By default a node could populate it's
children, but when faced with masses of data it may be more appropriate to
present your users with a search form and from there they can select the items
to add to the tree view for manipulation.

This makes sense, and it's something we should consider when testing
this application with "live".

  Stefano

#16721 From: "eben_roux" <eben.roux@...>
Date: Tue Dec 29, 2009 12:27 pm
Subject: Re: Entity, Repositories and Lazy Loading
eben_roux
Send Email Send Email
 
Hi Stefano,

I will not be able to tell if this is the case with your application but I have
noticed that sometimes reporting concerns are attached to the domain model.

These dynamically attached / arbitrary properties, are they *really* part of the
domain?  They sound quite a bit like a classification structure used to filter
or find your *real* objects.  The reason I say this is that should they be
required for the domain to function properly they would *have* to be part of the
domain and not linked in such an arbitrary fashion.

Then regarding the aneamic domain model: I'm actually refering to what is
nowadays called CQRS (command/query responsibility segregation) --- CQS on an
architectural level.  You don't need to even 'query' or use your repository. 
Your repository is for getting back entities and aggregates, so 100% concerned
with the domain.

You can create an entirely separate querying layer using something as simple as
a datatable or even DTOs when required.  And this can be used directly from your
front-end.

Regards,
Eben

#16722 From: Nuno Lopes <nbplopes@...>
Date: Tue Dec 29, 2009 12:46 pm
Subject: Re: Re: Entity, Repositories and Lazy Loading
nbplopes
Send Email Send Email
 
Hi Stefano,

There are at least two types of behavior:

1) Behavior governing change (business transactions)
2) Behavior governing reporting (business reporting)

IMHO the main reason to use a domain model is should be the complexity of 1) not so much two. For 2), data oriented tech is far better equipped both in theory and in practice then OO tech.

The underlying data model can be seen as specialized reporting model for the domain. So if you use your reporting model as the behavioral model governing reporting and the domain model as the behavioral model governing changes then you only need to worry about not making your domain model anaemic to changes.

Now if you domain model has little governance around changes of course removing 2) from its responsibilities would make it anaemic.  But if that is the case should we be really using a domain model for the problem at hand?

Does this make sense?

Nuno



#16723 From: Stefano Ricciardi <stefano.ricciardi@...>
Date: Tue Dec 29, 2009 2:06 pm
Subject: Re: Re: Entity, Repositories and Lazy Loading
sterioma
Send Email Send Email
 
On Tue, Dec 29, 2009 at 1:27 PM, eben_roux <eben.roux@...> wrote:
> I will not be able to tell if this is the case with your application but I
have noticed that sometimes reporting concerns are attached to the domain model.
>
> These dynamically attached / arbitrary properties, are they *really* part of
the domain? They sound quite a bit like a classification structure used to
filter or find your *real* objects. The reason I say this is that should they be
required for the domain to function properly they would *have* to be part of the
domain and not linked in such an arbitrary fashion.

From my point of view, these properties *are* part of the domain. They
characterize each business object the same way as zip code
characterize an address object.

The fact that they are not simple attributes to the object is because
the database schema itself is pretty "generic", allowing a business
object to have a few "simple" properties (most likely a column in that
objects table, such as the "name" for a financial "asset" in the table
containing all assets) and several "complex" properties, which might
reside in different tables, and have different values across time
(such as the time series of values representing the monetary value of
an asset for each day).

And they will not just be used to filter the objects but they will
also be displayed in reports, etc.. Google Stock Screener
(http://www.google.com/finance/stockscreener) vaguely looks like
something that we are trying to create (just it's not only related to
finance).

> Then regarding the aneamic domain model: I'm actually refering to what is
nowadays called CQRS (command/query responsibility segregation) --- CQS on an
architectural level. You don't need to even 'query' or use your repository. Your
repository is for getting back entities and aggregates, so 100% concerned with
the domain.
>
> You can create an entirely separate querying layer using something as simple
as a datatable or even DTOs when required. And this can be used directly from
your front-end.
>

Although I have heard about CQS from this list, I am not familiar with
it. I will google for it and see whether I can come up with something
that might be useful.

Thank you once again for your time!

  Stefano

#16724 From: "vvernon_shiftmethod" <vvernon@...>
Date: Tue Dec 29, 2009 2:05 pm
Subject: Re: Entity, Repositories and Lazy Loading
vvernon_shif...
Send Email Send Email
 
In theory Repository pattern says that you should never use it to find/read
anything within its corresponding Aggregate except for the corresponding
Aggregate Root instances. In reality, sometimes you need to tune your repository
to get things under the root, or to compute counts. In such cases there is no
need to conclude that you have discovered poorly designed Aggregates or Roots.
It's simply a matter of the realities of real world performance. However, you
might have other aggregates inside an AR that you could use other corresponding
repositories to do the finds of domain objects you need at any given time.

I am not out on a limb here. Eric stated this in a recent QCon presentation. The
title was something like "Things I've Learned Since Writing the Book."

Personally I am a largely a traditionalist and I don't consider View
requirements to be reporting. Traditionally in MVC (where M is the domain Model)
the Model is used by the View.

If you choose to take the CQRS approach recognize that it is a different "world
view." MVC doesn't prove CQRS wrong, and neither does CQRS prove MVC wrong.

Vaughn


--- In domaindrivendesign@yahoogroups.com, Stefano Ricciardi
<stefano.ricciardi@...> wrote:
>
> Hi,
>
> I have a rather peculiar domain where one of the entities models a
> taxonomy of properties for a particular business object.
> Oversimplifying, properties might have a first classification like
> "numeric", "literal" and "date-related". Within each category, further
> categories may be present thus creating a property tree.
>
> The UI will show the user a navigation tree (much like an explorer of
> a file system) to navigate through properties according to the
> taxonomy.
>
> I am modelling the property tree with an entity like the following:
>
> class PropertyTreeNode
> {
>    public PropertyDescriptor Descriptor { get; private set; }  // this
> contains metadata describing a property
>    public bool HasChildren() { //... }
>    public IEnumerable<PropertyTreeNode> GetChildren() { // .... }
>
>    // follows constructor and private methods...
> }
>
> One of the problems I will be facing is that a single node can
> potentially contain a *big*list of children. I would like to be able
> to lazy load a node's children only when requested (e.g. because the
> user wants to explore some part of a tree), without loading into
> memory the overall tree at once.
>
> However, I am not quite sure how to achieve this. As far as I
> understand, domain model classes shouldn't refer to the repository or
> any other infrastructure service. So, how can the domain model be
> hydrated in a lazy way in a situation like this?
>
> Thank you,
>  Stefano
>

#16725 From: Stefano Ricciardi <stefano.ricciardi@...>
Date: Tue Dec 29, 2009 4:11 pm
Subject: Re: Re: Entity, Repositories and Lazy Loading
sterioma
Send Email Send Email
 
On Tue, Dec 29, 2009 at 3:05 PM, vvernon_shiftmethod
<vvernon@...> wrote:

> In theory Repository pattern says that you should never use it to find/read
anything within its corresponding Aggregate except for the corresponding
Aggregate Root instances. In reality, sometimes you need to tune your repository
to get things under the root, or to compute counts. In such cases there is no
need to conclude that you have discovered poorly designed Aggregates or Roots.
It's simply a matter of the realities of real world performance. However, you
might have other aggregates inside an AR that you could use other corresponding
repositories to do the finds of domain objects you need at any given time.
>
> I am not out on a limb here. Eric stated this in a recent QCon presentation.
The title was something like "Things I've Learned Since Writing the Book."

This is somehow comforting. Looks like passing a reference to a
repository interface to the method fetching the children might not be
such a bad idea after all.

Thanks!
  Stefano

#16726 From: "george_mauer" <gmauer@...>
Date: Tue Dec 29, 2009 5:17 pm
Subject: Re: Entity, Repositories and Lazy Loading
george_mauer
Send Email Send Email
 
Stefano, sounds like you're where I was about half a year ago.  So let me explain a couple things to you that I wish had been told me.

First of all regarding this list.  I imagine the answers you have been receiving are not quite what you expected.  This is because most of the people on this lists are advocates of a CQRS (Command Query Responsibility Separation) approach.  This approach is seen by many as an evolution of what Eric Evans discusses in the Big Blue Book but on the surface looks quite different indeed.

You can find good descriptions of CQRS here  and here.  Videos linked to from here .  The basic gist is that the domain only really matters as far as you actually doing something with it.  It doesn't help much and can indeed get in the way when reporting or populating fields on a screen (which is a special case of reporting).  This boils down to the rule-of-thumb "don't have any getter properties on your domain objects".  Yes its a weird concept that takes a while to get your mind around, read the above links.

Of course you can do effective DDD without delving into CQRS.    There's a reason why so many people are looking that way, but let me answer your question with the assumption that you choose to stay the course and not introduce a new architecture philosophy into your project.

First of all let's define repository.  The meaning of the term has also evolved since the DDD book.  Nowadays I see repository refer more often to the responsibility of specifically "notifying the domain of changes to an aggregate root".  In other words IRepository<Cusotmer> has exactly one method - Save(Customer).  For fetching lists of customers you would use an interface named something like ICustomers, ICustomerQuery, or ICustomerProvider.  This separation of roles allows you to do some fairly neat optimizations down the road.  Notice that these are interfaces so they can still be implemented by the same object.  Since you are talking about fetching data I will use the term "provider" where you were using "repository".

Also, before we go anywhere your provider and repository abstractions (interfaces) should be in the same project as your domain and your implementations should be in a different one.  There is probably a different way of doing this, but that is the only one that I've ever seen.

This opens up possibility one.  If PropertyTreeNode is an aggregate root, while it is frowned upon to have PropertyTreeNode reference your IPropertyTreeNodeProvider, its not a hard and fast rule.  If you're ok with the domain containing the knowledge "the node might have a whole lot of children" then go ahead and lazy load directly in your domain object.

The second and far more involved solution is to use a proxy design pattern.

// This lives in the same layer as your IPropertyTreeNodeProvider Implementation
PropertyTreeNodeChildrenLoader : PropertyTreeNode {
  IPropertyTreeNodeProvider _provider;
  IEnumerable<PropertyTreeNode> _children;
  public PropertyTreeNodeChildrenLoader(IPropertyTreeNodeProvider provider){
     _provider = provider; }

  public override IEnumerable<PropertyTreeNode> GetChildren() {
     if(_children == null)
        _children = _provider.GetChildrenFor(this)
     return _children
  }
}


It works like this:
IPropertyTreeNodeProvider  nodeProvider = GetProvider();  // returns implementation from the data layer
PropertyTreeNode node = nodeProvider.GetById(1); //Actually returns PropertyTreeNodeChildrenLoader  but its a secret
PropertyTreeNode[] chldren = node.GetChildren().ToArray();  // does lazy load implicitly here

This is effectively what ORMs like NHibernate do.

Does that help?

--- In domaindrivendesign@yahoogroups.com, Stefano Ricciardi <stefano.ricciardi@...> wrote:
>
> Hi,
>
> I have a rather peculiar domain where one of the entities models a
> taxonomy of properties for a particular business object.
> Oversimplifying, properties might have a first classification like
> "numeric", "literal" and "date-related". Within each category, further
> categories may be present thus creating a property tree.
>
> The UI will show the user a navigation tree (much like an explorer of
> a file system) to navigate through properties according to the
> taxonomy.
>
> I am modelling the property tree with an entity like the following:
>
> class PropertyTreeNode
> {
>    public PropertyDescriptor Descriptor { get; private set; } // this
> contains metadata describing a property
>    public bool HasChildren() { //... }
>    public IEnumerable<PropertyTreeNode> GetChildren() { // .... }
>
> // follows constructor and private methods...
> }
>
> One of the problems I will be facing is that a single node can
> potentially contain a *big*list of children. I would like to be able
> to lazy load a node's children only when requested (e.g. because the
> user wants to explore some part of a tree), without loading into
> memory the overall tree at once.
>
> However, I am not quite sure how to achieve this. As far as I
> understand, domain model classes shouldn't refer to the repository or
> any other infrastructure service. So, how can the domain model be
> hydrated in a lazy way in a situation like this?
>
> Thank you,
> Stefano
>

#16727 From: "vvernon_shiftmethod" <vvernon@...>
Date: Tue Dec 29, 2009 5:19 pm
Subject: Re: Entity, Repositories and Lazy Loading
vvernon_shif...
Send Email Send Email
 
Here are a couple of versions of Eric's presentation:

http://www.infoq.com/presentations/ddd-eric-evans

http://domaindrivendesign.org/library/evans_2009_1

You could consider using a Domain Service in front to handle loading
intricacies, and working out whose going to hold on to newly cached references.

Also Randy Stafford uses "Disconnected Model" as a means to affect high
performance. This basically involves storing ids rather than associations. In
this case you could consider either using the Repository from the Domain
Service, or as you state, finding a way to use the Repository from a getter in
an Aggregate. Anyway, I'd suggest taking a look here:

http://archive.oredev.org/topmenu/video/ddd/randystafford.4.5a2d30d411ee6ffd2888\
0002199.html

For me passing in a Repository is less appealing than having it statically
injected (not instance, static) or referencing it from a Registry (some call it
Service Locator pattern) that has it injected for your convenience:

TreeNode tn = DomainRegistry.getTreeNodeRepository().findNode(aNodeId);

But this may be considered stylistic.

Vaughn


--- In domaindrivendesign@yahoogroups.com, Stefano Ricciardi
<stefano.ricciardi@...> wrote:
>
> On Tue, Dec 29, 2009 at 3:05 PM, vvernon_shiftmethod
> <vvernon@...> wrote:
>
> > In theory Repository pattern says that you should never use it to find/read
anything within its corresponding Aggregate except for the corresponding
Aggregate Root instances. In reality, sometimes you need to tune your repository
to get things under the root, or to compute counts. In such cases there is no
need to conclude that you have discovered poorly designed Aggregates or Roots.
It's simply a matter of the realities of real world performance. However, you
might have other aggregates inside an AR that you could use other corresponding
repositories to do the finds of domain objects you need at any given time.
> >
> > I am not out on a limb here. Eric stated this in a recent QCon presentation.
The title was something like "Things I've Learned Since Writing the Book."
>
> This is somehow comforting. Looks like passing a reference to a
> repository interface to the method fetching the children might not be
> such a bad idea after all.
>
> Thanks!
>  Stefano
>

#16728 From: "eben_roux" <eben.roux@...>
Date: Tue Dec 29, 2009 6:19 pm
Subject: Re: Entity, Repositories and Lazy Loading
eben_roux
Send Email Send Email
 
Hey Stefano,

OK.  I would still stay away from calling it something like a PropertyNode. 
Someone has mentioned something along the lines of a 'Facet'.  Nuno, was it you?

Anyway, directly querying the data store works great.  I have tried it on my
current project using one data store for both the domain and reporting.  In
fact, using denormalized data in the same tables.  In my case it is possible
since it is a very simple and low-volume application.

I don't use domain objects in my front-end so I have a slightly different take
on MVC to that of Vaughn.  The M represents a presentation model.  In many
instances that presentation model is a simple DataTable or even a DataRow.  When
I have added complexity in the structure or derived data then I will use a DTO.

I also don't buy into the Repository only being used to load aggregate roots ---
they can load any entity that requires global access.  By saying that I do *not*
mean that you should access entites within an aggregate directly but should
rather go through the aggregate representation or the aggregate root entity if
that makes sense in your scenario.

Regards,
Eben


--- In domaindrivendesign@yahoogroups.com, Stefano Ricciardi
<stefano.ricciardi@...> wrote:
>
> On Tue, Dec 29, 2009 at 1:27 PM, eben_roux <eben.roux@...> wrote:
> > I will not be able to tell if this is the case with your application but I
have noticed that sometimes reporting concerns are attached to the domain model.
> >
> > These dynamically attached / arbitrary properties, are they *really* part of
the domain? They sound quite a bit like a classification structure used to
filter or find your *real* objects. The reason I say this is that should they be
required for the domain to function properly they would *have* to be part of the
domain and not linked in such an arbitrary fashion.
>
> From my point of view, these properties *are* part of the domain. They
> characterize each business object the same way as zip code
> characterize an address object.
>
> The fact that they are not simple attributes to the object is because
> the database schema itself is pretty "generic", allowing a business
> object to have a few "simple" properties (most likely a column in that
> objects table, such as the "name" for a financial "asset" in the table
> containing all assets) and several "complex" properties, which might
> reside in different tables, and have different values across time
> (such as the time series of values representing the monetary value of
> an asset for each day).
>
> And they will not just be used to filter the objects but they will
> also be displayed in reports, etc.. Google Stock Screener
> (http://www.google.com/finance/stockscreener) vaguely looks like
> something that we are trying to create (just it's not only related to
> finance).
>
> > Then regarding the aneamic domain model: I'm actually refering to what is
nowadays called CQRS (command/query responsibility segregation) --- CQS on an
architectural level. You don't need to even 'query' or use your repository. Your
repository is for getting back entities and aggregates, so 100% concerned with
the domain.
> >
> > You can create an entirely separate querying layer using something as simple
as a datatable or even DTOs when required. And this can be used directly from
your front-end.
> >
>
> Although I have heard about CQS from this list, I am not familiar with
> it. I will google for it and see whether I can come up with something
> that might be useful.
>
> Thank you once again for your time!
>
>  Stefano
>

#16729 From: Stefano Ricciardi <stefano.ricciardi@...>
Date: Tue Dec 29, 2009 8:51 pm
Subject: Re: Re: Entity, Repositories and Lazy Loading
sterioma
Send Email Send Email
 
All,

thank you for all the feedback and links that you have sent. A lot of material to go through (and I haven't even finished reading the blue book yet LOL! :)).

 Stefano




On Tue, Dec 29, 2009 at 7:19 PM, eben_roux <eben.roux@...> wrote:
 

Hey Stefano,

OK. I would still stay away from calling it something like a PropertyNode. Someone has mentioned something along the lines of a 'Facet'. Nuno, was it you?

Anyway, directly querying the data store works great. I have tried it on my current project using one data store for both the domain and reporting. In fact, using denormalized data in the same tables. In my case it is possible since it is a very simple and low-volume application.

I don't use domain objects in my front-end so I have a slightly different take on MVC to that of Vaughn. The M represents a presentation model. In many instances that presentation model is a simple DataTable or even a DataRow. When I have added complexity in the structure or derived data then I will use a DTO.

I also don't buy into the Repository only being used to load aggregate roots --- they can load any entity that requires global access. By saying that I do *not* mean that you should access entites within an aggregate directly but should rather go through the aggregate representation or the aggregate root entity if that makes sense in your scenario.

Regards,
Eben



--- In domaindrivendesign@yahoogroups.com, Stefano Ricciardi <stefano.ricciardi@...> wrote:
>
> On Tue, Dec 29, 2009 at 1:27 PM, eben_roux <eben.roux@...> wrote:
> > I will not be able to tell if this is the case with your application but I have noticed that sometimes reporting concerns are attached to the domain model.
> >
> > These dynamically attached / arbitrary properties, are they *really* part of the domain? They sound quite a bit like a classification structure used to filter or find your *real* objects. The reason I say this is that should they be required for the domain to function properly they would *have* to be part of the domain and not linked in such an arbitrary fashion.
>
> From my point of view, these properties *are* part of the domain. They
> characterize each business object the same way as zip code
> characterize an address object.
>
> The fact that they are not simple attributes to the object is because
> the database schema itself is pretty "generic", allowing a business
> object to have a few "simple" properties (most likely a column in that
> objects table, such as the "name" for a financial "asset" in the table
> containing all assets) and several "complex" properties, which might
> reside in different tables, and have different values across time
> (such as the time series of values representing the monetary value of
> an asset for each day).
>
> And they will not just be used to filter the objects but they will
> also be displayed in reports, etc.. Google Stock Screener
> (http://www.google.com/finance/stockscreener) vaguely looks like
> something that we are trying to create (just it's not only related to
> finance).
>
> > Then regarding the aneamic domain model: I'm actually refering to what is nowadays called CQRS (command/query responsibility segregation) --- CQS on an architectural level. You don't need to even 'query' or use your repository. Your repository is for getting back entities and aggregates, so 100% concerned with the domain.
> >
> > You can create an entirely separate querying layer using something as simple as a datatable or even DTOs when required. And this can be used directly from your front-end.
> >
>
> Although I have heard about CQS from this list, I am not familiar with
> it. I will google for it and see whether I can come up with something
> that might be useful.
>
> Thank you once again for your time!
>
> Stefano
>



#16730 From: "vvernon_shiftmethod" <vvernon@...>
Date: Wed Dec 30, 2009 12:01 am
Subject: Framework Annotations On Domain Objects
vvernon_shif...
Send Email Send Email
 
How do you feel about putting framework annotations on domain objects? For
example, what if you had to use annotations to mark some N/Hibernate persistent
attributes/properties or associations? The same goes for JPA or JDO or whatever.

I think Rickard uses them for Qi4J, but perhaps they are considerably different
(cleaner?) than others.

This isn't bad: @Entity

This seems nasty: @Table(name="tbl_sky")

And then there are the import/using statements.

To me it's a like putting infrastructure in the model. But I imagine some
consider this acceptable if it reduces complexity in other ways. And no doubt if
you are willing to run with defaults then the less abstract annotations can be
avoided. Opinions please.

Thanks!

Vaughn

#16731 From: Frederic Marceau <fmarceau@...>
Date: Wed Dec 30, 2009 12:11 am
Subject: Re: Framework Annotations On Domain Objects
fmarceau...
Send Email Send Email
 
For many years, I been using XML hibernate mapping files because of the persistence ignorance thing. But, since I'm doing a lot of .NET projects recently, my hatred for XML configuration files grows with the time.

I agree 100% with you, @Entity, @Transactional are GOOD but @Table(name="...") is kinda leaky.

But are there proved alternatives?

F.

On 2009-12-29 19:01, vvernon_shiftmethod wrote:
 

How do you feel about putting framework annotations on domain objects? For example, what if you had to use annotations to mark some N/Hibernate persistent attributes/properties or associations? The same goes for JPA or JDO or whatever.

I think Rickard uses them for Qi4J, but perhaps they are considerably different (cleaner?) than others.

This isn't bad: @Entity

This seems nasty: @Table(name="tbl_sky")

And then there are the import/using statements.

To me it's a like putting infrastructure in the model. But I imagine some consider this acceptable if it reduces complexity in other ways. And no doubt if you are willing to run with defaults then the less abstract annotations can be avoided. Opinions please.

Thanks!

Vaughn



#16732 From: Richard Dingwall <rdingwall@...>
Date: Wed Dec 30, 2009 3:02 am
Subject: Re: Framework Annotations On Domain Objects
rdingwall@...
Send Email Send Email
 
On Wed, Dec 30, 2009 at 1:11 PM, Frederic Marceau <fmarceau@...> wrote:
>
>
>
> For many years, I been using XML hibernate mapping files because of the
persistence ignorance thing. But, since I'm doing a lot of .NET projects
recently, my hatred for XML configuration files grows with the time.
>
> I agree 100% with you, @Entity, @Transactional are GOOD but @Table(name="...")
is kinda leaky.
>
> But are there proved alternatives?

I like using explicit domain roles e.g.

- IAggregateRoot
- IDomainService
- IDomainEvent

But persistence concerns are kept far outside the domain model layer
e.g. in NHibernate .hbm.xml files or FluentNHibernate class mappings.
Transactions also do not belong in the domain; the scope of a
transaction is decided at the application service/API level, not the
domain model.

--
Richard Dingwall
http://richarddingwall.name

#16733 From: Frederic Marceau <fmarceau@...>
Date: Wed Dec 30, 2009 3:09 am
Subject: Re: Framework Annotations On Domain Objects
fmarceau...
Send Email Send Email
 
Indeed, Fluent NHibernate is a VERY nice way of annotating a domain model object without "touching" it. Something like that should be done in the Java world.

The @Transactional annotation has been made for EJBs so it IS actually annotating services :)

F.

On 2009-12-29 22:02, Richard Dingwall wrote:
 

On Wed, Dec 30, 2009 at 1:11 PM, Frederic Marceau <fmarceau@abilis.ca> wrote:
>
>
>
> For many years, I been using XML hibernate mapping files because of the persistence ignorance thing. But, since I'm doing a lot of .NET projects recently, my hatred for XML configuration files grows with the time.
>
> I agree 100% with you, @Entity, @Transactional are GOOD but @Table(name="...") is kinda leaky.
>
> But are there proved alternatives?

I like using explicit domain roles e.g.

- IAggregateRoot
- IDomainService
- IDomainEvent

But persistence concerns are kept far outside the domain model layer
e.g. in NHibernate .hbm.xml files or FluentNHibernate class mappings.
Transactions also do not belong in the domain; the scope of a
transaction is decided at the application service/API level, not the
domain model.

--
Richard Dingwall
http://richarddingwall.name



#16734 From: Tomas Karlsson <tomas.lg.karlsson@...>
Date: Wed Dec 30, 2009 8:39 am
Subject: Re: Framework Annotations On Domain Objects
marcellus874
Send Email Send Email
 
Hi,

After five years with DDD, EJB and Hibernate I have found that annotations in the Domain objects is the best solution. It adds non-Domain stuff to the Domain classes, so they are not "pure" from a dogmatic perspective... But in real life, the advantage of having both the definition of classes and attributes with their persistence directives (annotations) close to each other in the same file is huge, especially when you refactor. Compare this to make changes in one Java file and one XML file - every time you refactor.

This was my opinion. I know that the DDD Sample Application uses XML files to make the Domain classes pure. And maybe that's the right solution for a sample application? Clearly showing DDD is more important than productivity in refactoring! In the projects I am working, the opposite is true. So this is a question where one size does not fit all.

/Tomas

PS I will look at Fluent NHibernate. Looks like a great idea.

vvernon_shiftmethod skrev:
 

How do you feel about putting framework annotations on domain objects? For example, what if you had to use annotations to mark some N/Hibernate persistent attributes/properties or associations? The same goes for JPA or JDO or whatever.

I think Rickard uses them for Qi4J, but perhaps they are considerably different (cleaner?) than others.

This isn't bad: @Entity

This seems nasty: @Table(name="tbl_sky")

And then there are the import/using statements.

To me it's a like putting infrastructure in the model. But I imagine some consider this acceptable if it reduces complexity in other ways. And no doubt if you are willing to run with defaults then the less abstract annotations can be avoided. Opinions please.

Thanks!

Vaughn



#16735 From: Nuno Lopes <nbplopes@...>
Date: Wed Dec 30, 2009 11:27 am
Subject: Re: Re: Entity, Repositories and Lazy Loading
nbplopes
Send Email Send Email
 
@Eben

OK. I would still stay away from calling it something like a PropertyNode. Someone has mentioned something along the lines of a 'Facet'. Nuno, was it you?

You have a good memory mate. Yes, in some other thread. 

@Stefano,

I don't much about your domain but here is what I get from what you said.


... I have a rather peculiar domain where one of the entities models a
taxonomy of properties for a particular business object. ...


... My domain model in this case is basically a group of business objects
(that can be of different nature (in a financial context it might be
for example an asset, a portfolio, a customer, etc...)) and a set of
dynamic properties that might be defined on those business objects....

To me this suggests that you have at least two bounded contexts in DDD terms. Say "Portfolio Management" and "Business Taxonomy Management"

The second deals with managing classification of entities of the first.

The main use case is to allow the user to pick a business object type
(say a bond), browse through its properties (dynamically loaded from
the DB) and from there filter business objects based on the *values*
of one or more property (say, overall value, currency, etc..).

It seams that you classification is made towards dynamically building filters. Faceted classification approach can help you with that. Check an example around wines: http://facetmap.com/browse/

There are many way to build a faceted classification scheme, but we have first to agree that the bounded context is one of facet classification for business entities not bonds. We can later relate the business entities to the classification.

Business Taxonomy Management (Bounded Context)

Now that we have our context fixed, we can discuss its entities:

FacetedResource - Ex: FacetedResource is a role of an external Entity within this bounded context. Entities can be Bonds, Assets whatever you think of.
Facet - HighPrice, France, Dollar ... etc etc
FacetTaxonomy: A taxonomy is say Price, Type, Currency, ZipCode, Region ... etc etc

So a FacetTaxonomy is a three structure of facets. Here is what could be defined has a FacetedResource

class FacetedResource
{
     Guid ResourceID; // the id of a Bond, an Asset a Customer whatever.
     string ResourceType; // the type of the resource (Bond, Asset, whatever);
     IList<Facet> Facets; // a list of facets of the resource.
}

Here is an example of a specification of a faceted classification: http://facetmap.com/conf/wine.txt

In my experience a domain model supporting a faceted classification scheme has little behavior in it unless it embeds some kind of automatic classification. So I'm not quite sure is a domain model is necessary. Maybe a simple class diagram and some services around it is just enough. Indeed I would even risk to say that considering your use case and taking the perspective of the "Porfolio Management" classification and filtering might be considered a reporting issue.

So now the question is now, what would be the engine of a "faceted reporting system"? Should it be provided by an RDBMS? CouchDB? A Free-text Search Engine? Should we make a custom engine?

The Reporting System (The Engine)

It all depends on the amount of information you want to navigated and classify. But for a faceted classification FTS engines offers IMHO the most straight forward solution (think for instance a google search box).

The FTS would index FacetedResources by "looking" at its list of facets. A FacetedResource can be persisted in XML or in a simple text file:

ResourceID: 2212
ResourceName: ....
Facets: VALUE(<10.000), TYPE(Bond), CURRENCY(Dollar), .....

Take you use case. The user browses the taxonomy in a way similar to the wine demo. Every time the user clicks on a facet the system constructs a FTS query. 

1) Clicks on "Bond" add TYPE(BOND) and calls the engine.
2) Clicks on "Dollar" adds CURRENCY(Dollar). So we no have TYPE(Bond), CURRENCY(Dollar)
......

So all the system would have to do is Engine.Query("TYPE(Bond) CURRENCY(Dollar)") and it would return the bonds transactioned in dollars.

Automatic Classification

Take your Portfolios. After adding an asset to a portfolio how will this asset be classified? After classification how will it used to feed the engine?

Have you though how will the business entities by classified? If you follow the root of automatic classification then you might consider that your probably have a domain model to support the calculation of a FacetedResource given a Resource (say Bond). This domain model might even have a DSL allowing the specification of classification rules.

Feeding the Reporting Engine

So we have our two BCs Porfolio Management, Business Taxonomy Management and a Reporting System (Faceted Reporting)

CQRS can help you with that. After adding an asset to a portfolio, an event AssetAdded is fired or published (depends if you want classification process to be synchronous or asynchronous). This event is then captured by the Business Taxonomy Management BC and it will classify the Asset (this classification can be automatic using some rules engine). After classification an event is fired/published FacetedResourceClassified that is then captured by the "Faceted Reporting Engine" (The Reporting System) that will get the data in the event, persist to to a file (for instance) and later will index it.

To lazy load or not to lazy load.

Taking this perspective over a systems architecture, to lazy load or not to lazy load a Facets becomes a minor challenge. Don't know quite well what you mean by a lot of properties. Personally to support navigation over the taxonomy I would query the data model underlying the FacedTaxonomy directly (if you have one) Bypassing the object model entirely. But this depends greatly on the technology used for persisting these entities.

Something like:

Query.GetFacets(taxonomyId, nodeId) would be enough. It would return a set of Facet DTOs (XML doc, .NET Table, whatever).

Wrapping Up

As you can see if you take the concepts of Bounded Context, Roles, CQRS (Domain Events, Transaction System, Reporting System) helps reasoning around e a domain models and an architectures. Especially the concept of Roles intertwined with  Bounded Context and Conceptual Contours helps us to keep focus and find new hidden domains making them explicit.

Hope this helps. Happy journey.

Cheers,

Nuno








#16736 From: Nuno Lopes <nbplopes@...>
Date: Wed Dec 30, 2009 12:21 pm
Subject: Re: Framework Annotations On Domain Objects
nbplopes
Send Email Send Email
 
Hi,

I tend to agree with Thomas. My experience is mostly in .NET so we use
Attributes. It would be nice to have an IDE where we could hide/show attributes
per kind of view (domain model view, persistence view etc).

Fluent NHibernate looks better then XML, yet still we would have to deal with
two files instead of one something to keep and look when refacturing.

The main advantages IMHO areÇ

1) Compile time checks
2) Is less verbose then ebm.
3) It is just plane standard C# code.

Cheers,

Nuno
PS: I lack experience with Fluent NHibernate to formulate an opinion if it helps
or not the refacturing process more the attributes. In principle I would say yes
since it checks stuff at compile time.

#16737 From: Rickard Öberg <rickardoberg@...>
Date: Wed Dec 30, 2009 12:35 pm
Subject: Re: Framework Annotations On Domain Objects
rickardoberg
Send Email Send Email
 
On 2009-12-30 01.01, vvernon_shiftmethod wrote:
> How do you feel about putting framework annotations on domain objects?
> For example, what if you had to use annotations to mark some N/Hibernate
> persistent attributes/properties or associations? The same goes for JPA
> or JDO or whatever.
>
> I think Rickard uses them for Qi4J, but perhaps they are considerably
> different (cleaner?) than others.

All Qi4j annotations are related to domain concerns, rather than
infrastructure concerns. In essence, we are using them to extend the
regular Java language, instead of creating a new language. We don't have
any annotations like that @Table one. There are some that are decidedly
"gray" though, like @Queryable, which could be seen as both domain and
infrastructure concepts.

/Rickard

#16738 From: Frederic Marceau <fmarceau@...>
Date: Wed Dec 30, 2009 12:59 pm
Subject: Re: Framework Annotations On Domain Objects
fmarceau...
Send Email Send Email
 
Everything that's related to any data access pattern (i.e. Repository, Data Mapper, etc.) is kosher to me. So @Queryable is perfectly acceptable since it gives some meta information to the repository about how to domain model can be queried. On the other side, @Table(name="") and @Column(name="") is evil.

When working on a greenfield project, you can use convention over configuration to avoid any mapping at all. For a brownfield project, I guess you have to deal with XML mapping files :/

F.

On 2009-12-30 07:35, Rickard Öberg wrote:
 

On 2009-12-30 01.01, vvernon_shiftmethod wrote:
> How do you feel about putting framework annotations on domain objects?
> For example, what if you had to use annotations to mark some N/Hibernate
> persistent attributes/properties or associations? The same goes for JPA
> or JDO or whatever.
>
> I think Rickard uses them for Qi4J, but perhaps they are considerably
> different (cleaner?) than others.

All Qi4j annotations are related to domain concerns, rather than
infrastructure concerns. In essence, we are using them to extend the
regular Java language, instead of creating a new language. We don't have
any annotations like that @Table one. There are some that are decidedly
"gray" though, like @Queryable, which could be seen as both domain and
infrastructure concepts.

/Rickard



#16739 From: Rickard Öberg <rickardoberg@...>
Date: Wed Dec 30, 2009 2:26 pm
Subject: Re: Framework Annotations On Domain Objects
rickardoberg
Send Email Send Email
 
On 2009-12-30 13.59, Frederic Marceau wrote:
> Everything that's related to any data access pattern (i.e. Repository,
> Data Mapper, etc.) is kosher to me. So @Queryable is perfectly
> acceptable since it gives some meta information to the repository about
> how to domain model can be queried. On the other side, @Table(name="")
> and @Column(name="") is evil.

The problem I am seeing is that whether something is queryable or not,
i.e. whether the property or association should be indexed or not, is
really something that is *mostly* UI-related (i.e. not infrastructure
but on the other end). Some queries are domain-oriented, but most are
for the purpose of UI's or reporting. So is it ok to add @Queryable to
the domain classes if they need to be queried for the UI? Probably not,
since the UI has a higher change-rate compared to the domain.

But where to put that information instead? I don't know. Definitely not
easy to know.

/Rickard

#16740 From: Abraham Block <atblock@...>
Date: Wed Dec 30, 2009 12:15 am
Subject: Re: Framework Annotations On Domain Objects
avihock
Send Email Send Email
 
There is fluent NHibernate.

On Tue, Dec 29, 2009 at 7:11 PM, Frederic Marceau <fmarceau@...> wrote:
 

For many years, I been using XML hibernate mapping files because of the persistence ignorance thing. But, since I'm doing a lot of .NET projects recently, my hatred for XML configuration files grows with the time.

I agree 100% with you, @Entity, @Transactional are GOOD but @Table(name="...") is kinda leaky.

But are there proved alternatives?

F.



On 2009-12-29 19:01, vvernon_shiftmethod wrote:
 

How do you feel about putting framework annotations on domain objects? For example, what if you had to use annotations to mark some N/Hibernate persistent attributes/properties or associations? The same goes for JPA or JDO or whatever.

I think Rickard uses them for Qi4J, but perhaps they are considerably different (cleaner?) than others.

This isn't bad: @Entity

This seems nasty: @Table(name="tbl_sky")

And then there are the import/using statements.

To me it's a like putting infrastructure in the model. But I imagine some consider this acceptable if it reduces complexity in other ways. And no doubt if you are willing to run with defaults then the less abstract annotations can be avoided. Opinions please.

Thanks!

Vaughn




#16741 From: "vvernon_shiftmethod" <vvernon@...>
Date: Wed Dec 30, 2009 4:07 pm
Subject: Re: Framework Annotations On Domain Objects
vvernon_shif...
Send Email Send Email
 
@Rickard: Perhaps you want to put it on the UI and inject it onto the domain
object(s) during build or startup (AOP).

@All: Thanks for your input. Given a choice I'd continue with XML files or the
fluent approach, for ORM concerns, unless using a cleaner Qi4j framework. My
main reason for my question is because in some environments you could have no
choice. For example, does Google App Engine support the DataNucleus XML mappings
for JPA, or only their annotations? I only see docs for annotations, but the
annotations are fairly abstract. Many developers probably choose a platform
(cloud or whatever) because of the technologies they can use. Others may be
forced by business direction. While I have a strong preference, I can see as a
tool developer that I'd probably want to support those who like or need that
sort of thing.

Vaughn


--- In domaindrivendesign@yahoogroups.com, Rickard Öberg <rickardoberg@...>
wrote:
>
> On 2009-12-30 13.59, Frederic Marceau wrote:
> > Everything that's related to any data access pattern (i.e. Repository,
> > Data Mapper, etc.) is kosher to me. So @Queryable is perfectly
> > acceptable since it gives some meta information to the repository about
> > how to domain model can be queried. On the other side, @Table(name="")
> > and @Column(name="") is evil.
>
> The problem I am seeing is that whether something is queryable or not,
> i.e. whether the property or association should be indexed or not, is
> really something that is *mostly* UI-related (i.e. not infrastructure
> but on the other end). Some queries are domain-oriented, but most are
> for the purpose of UI's or reporting. So is it ok to add @Queryable to
> the domain classes if they need to be queried for the UI? Probably not,
> since the UI has a higher change-rate compared to the domain.
>
> But where to put that information instead? I don't know. Definitely not
> easy to know.
>
> /Rickard
>

#16742 From: "leojhartiv" <leo.hart@...>
Date: Thu Dec 31, 2009 2:38 pm
Subject: Re: Framework Annotations On Domain Objects
leojhartiv
Send Email Send Email
 
I think the only real bummer for me in regards to the externalized ORM mapping
files is the refactoring and lack of compile-time support.

If Hibernate provided an externalized java-based configuration, similar to what
Spring is doing with their JavaConfig project, that would be the best of both
worlds.  I'm crazy about the table/column annotations buried in the domain, but
I certainly don't like the additional work using XML either.



--- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@...>
wrote:
>
> @Rickard: Perhaps you want to put it on the UI and inject it onto the domain
object(s) during build or startup (AOP).
>
> @All: Thanks for your input. Given a choice I'd continue with XML files or the
fluent approach, for ORM concerns, unless using a cleaner Qi4j framework. My
main reason for my question is because in some environments you could have no
choice. For example, does Google App Engine support the DataNucleus XML mappings
for JPA, or only their annotations? I only see docs for annotations, but the
annotations are fairly abstract. Many developers probably choose a platform
(cloud or whatever) because of the technologies they can use. Others may be
forced by business direction. While I have a strong preference, I can see as a
tool developer that I'd probably want to support those who like or need that
sort of thing.
>
> Vaughn
>
>
> --- In domaindrivendesign@yahoogroups.com, Rickard Öberg <rickardoberg@>
wrote:
> >
> > On 2009-12-30 13.59, Frederic Marceau wrote:
> > > Everything that's related to any data access pattern (i.e. Repository,
> > > Data Mapper, etc.) is kosher to me. So @Queryable is perfectly
> > > acceptable since it gives some meta information to the repository about
> > > how to domain model can be queried. On the other side, @Table(name="")
> > > and @Column(name="") is evil.
> >
> > The problem I am seeing is that whether something is queryable or not,
> > i.e. whether the property or association should be indexed or not, is
> > really something that is *mostly* UI-related (i.e. not infrastructure
> > but on the other end). Some queries are domain-oriented, but most are
> > for the purpose of UI's or reporting. So is it ok to add @Queryable to
> > the domain classes if they need to be queried for the UI? Probably not,
> > since the UI has a higher change-rate compared to the domain.
> >
> > But where to put that information instead? I don't know. Definitely not
> > easy to know.
> >
> > /Rickard
> >
>

#16743 From: "leojhartiv" <leo.hart@...>
Date: Thu Dec 31, 2009 2:58 pm
Subject: Re: Framework Annotations On Domain Objects
leojhartiv
Send Email Send Email
 
That should read "I'm not crazy about the table/column..."

--- In domaindrivendesign@yahoogroups.com, "leojhartiv" <leo.hart@...> wrote:
>
> I think the only real bummer for me in regards to the externalized ORM mapping
files is the refactoring and lack of compile-time support.
>
> If Hibernate provided an externalized java-based configuration, similar to
what Spring is doing with their JavaConfig project, that would be the best of
both worlds.  I'm crazy about the table/column annotations buried in the domain,
but I certainly don't like the additional work using XML either.
>
>
>
> --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@>
wrote:
> >
> > @Rickard: Perhaps you want to put it on the UI and inject it onto the domain
object(s) during build or startup (AOP).
> >
> > @All: Thanks for your input. Given a choice I'd continue with XML files or
the fluent approach, for ORM concerns, unless using a cleaner Qi4j framework. My
main reason for my question is because in some environments you could have no
choice. For example, does Google App Engine support the DataNucleus XML mappings
for JPA, or only their annotations? I only see docs for annotations, but the
annotations are fairly abstract. Many developers probably choose a platform
(cloud or whatever) because of the technologies they can use. Others may be
forced by business direction. While I have a strong preference, I can see as a
tool developer that I'd probably want to support those who like or need that
sort of thing.
> >
> > Vaughn
> >
> >
> > --- In domaindrivendesign@yahoogroups.com, Rickard Öberg <rickardoberg@>
wrote:
> > >
> > > On 2009-12-30 13.59, Frederic Marceau wrote:
> > > > Everything that's related to any data access pattern (i.e. Repository,
> > > > Data Mapper, etc.) is kosher to me. So @Queryable is perfectly
> > > > acceptable since it gives some meta information to the repository about
> > > > how to domain model can be queried. On the other side, @Table(name="")
> > > > and @Column(name="") is evil.
> > >
> > > The problem I am seeing is that whether something is queryable or not,
> > > i.e. whether the property or association should be indexed or not, is
> > > really something that is *mostly* UI-related (i.e. not infrastructure
> > > but on the other end). Some queries are domain-oriented, but most are
> > > for the purpose of UI's or reporting. So is it ok to add @Queryable to
> > > the domain classes if they need to be queried for the UI? Probably not,
> > > since the UI has a higher change-rate compared to the domain.
> > >
> > > But where to put that information instead? I don't know. Definitely not
> > > easy to know.
> > >
> > > /Rickard
> > >
> >
>

#16744 From: "vvernon_shiftmethod" <vvernon@...>
Date: Thu Dec 31, 2009 5:17 pm
Subject: Re: Framework Annotations On Domain Objects
vvernon_shif...
Send Email Send Email
 
My way around that issue is initially to use a generative approach. I have an
abstract textual DSL model that only requires a few metaclasses, but can
generate a large portion of the domain model, including database script, XML
mappings, and of course the DDD-based model. The model is complete with
aggregates, entities, value objects, repositories, domain services, and wired
for IoC container.

The benefits of long-term refactoring could be less thrilling, because I don't
necessarily see the tool as a being used far past a 1.0 model. However, the
initial reduction in time to implementation is significant--potentially a few
days rather than weeks or months. You can generate model refactorings in
seconds; even experiment with broadly different approaches. And depending on the
team's mentality it could be employed longer term.

I think languages and tooling are what's going to save us from these
complexities and the competing forces of balancing elegance with time to market.
The tools ultimately need to be flexible enough to support a range of team
approaches (e.g. XML mappings vs annotations).

I think the DDD implementation refactoring patterns are in our minds, but they
haven't made it into IDEs like the typical general purpose language
refactorings. It's likely that some see annotations as a way around refactoring
tools. But then we meet the vicious cycle of, for example, pure and elegant vs
dirty and brute-force models. Tools always lag too far behind the great leaps
forward in methods.

Vaughn


--- In domaindrivendesign@yahoogroups.com, "leojhartiv" <leo.hart@...> wrote:
>
> I think the only real bummer for me in regards to the externalized ORM mapping
files is the refactoring and lack of compile-time support.
>
> If Hibernate provided an externalized java-based configuration, similar to
what Spring is doing with their JavaConfig project, that would be the best of
both worlds.  I'm crazy about the table/column annotations buried in the domain,
but I certainly don't like the additional work using XML either.
>
>
>
> --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@>
wrote:
> >
> > @Rickard: Perhaps you want to put it on the UI and inject it onto the domain
object(s) during build or startup (AOP).
> >
> > @All: Thanks for your input. Given a choice I'd continue with XML files or
the fluent approach, for ORM concerns, unless using a cleaner Qi4j framework. My
main reason for my question is because in some environments you could have no
choice. For example, does Google App Engine support the DataNucleus XML mappings
for JPA, or only their annotations? I only see docs for annotations, but the
annotations are fairly abstract. Many developers probably choose a platform
(cloud or whatever) because of the technologies they can use. Others may be
forced by business direction. While I have a strong preference, I can see as a
tool developer that I'd probably want to support those who like or need that
sort of thing.
> >
> > Vaughn
> >
> >
> > --- In domaindrivendesign@yahoogroups.com, Rickard Öberg <rickardoberg@>
wrote:
> > >
> > > On 2009-12-30 13.59, Frederic Marceau wrote:
> > > > Everything that's related to any data access pattern (i.e. Repository,
> > > > Data Mapper, etc.) is kosher to me. So @Queryable is perfectly
> > > > acceptable since it gives some meta information to the repository about
> > > > how to domain model can be queried. On the other side, @Table(name="")
> > > > and @Column(name="") is evil.
> > >
> > > The problem I am seeing is that whether something is queryable or not,
> > > i.e. whether the property or association should be indexed or not, is
> > > really something that is *mostly* UI-related (i.e. not infrastructure
> > > but on the other end). Some queries are domain-oriented, but most are
> > > for the purpose of UI's or reporting. So is it ok to add @Queryable to
> > > the domain classes if they need to be queried for the UI? Probably not,
> > > since the UI has a higher change-rate compared to the domain.
> > >
> > > But where to put that information instead? I don't know. Definitely not
> > > easy to know.
> > >
> > > /Rickard
> > >
> >
>

Messages 16715 - 16744 of 24071   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help