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

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
>

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

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
>

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

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

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

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
>

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

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
>

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
>

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

 

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

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

 

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

 

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

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.

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

 

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

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

@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
>

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
> >
>

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
> > >
> >
>

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
> > >
> >
>