Re: Re: Framework Annotations On Domain Objects

On 2009-12-30 17.07, vvernon_shiftmethod wrote:
  > @Rickard: Perhaps you want to put it on the UI and inject it onto the
> domain object(s) during build or startup (AOP).

Well, the code to actually do the indexing is totally separate, so the 
only question is where to put information about what to index. If I put 
it in the domain, then some of those things will be there just because 
the UI needs to query it. If I don't put it there it would have to be 
done through other more cumbersome methods, and it won't be as easily 
visible.

/Rickard

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

Re: Framework Annotations On Domain Objects

Re: Framework Annotations On Domain Objects

> only question is where to put information about
> what to index. If I put it in the domain, then
> some of those things will be there just because
> the UI needs to query it. If I don't put it there
> it would have to be done through other more
> cumbersome methods, and it won't be as easily 
> visible.

That's what leads me back to language, which is DSL in my case. I can concentrate metadata on whatever type I
need, and then generate the pieces elegantly. If I need an index on an attribute/property or a group of them
I just declare it in the DSL, the index shows up in the right place, and neither my UI nor my model need to know
about it. The same thing goes for various finders on repositories.

Even though annotations, when really well designed, fit in in many or most cases, I generally always find a
place where it is uncomfortable at best. It's one of the main reasons I didn't use an annotation approach
for my tool. Of course nothing is perfect, and admittedly there are reasons some don't like DSLs or
abstract modeling of any kind. So even if Qi4j has some "gray" areas it might not be so bad as to call it a wart.

Maybe your quandary is pointing to a need that isn't annotation based. Would there be an acceptable way to
declare what is needed without using annotations? A very skinny DSL or something like that could be
better, especially if it were strongly UI oriented and only referential to the model. Maybe there are even
other UI concerns that would find a good home there.

Vaughn

--- In domaindrivendesign <at> yahoogroups.com, Rickard Öberg <rickardoberg@...> wrote:
>
> On 2009-12-30 17.07, vvernon_shiftmethod wrote:
>   > @Rickard: Perhaps you want to put it on the UI and inject it onto the
> > domain object(s) during build or startup (AOP).
> 
> Well, the code to actually do the indexing is totally separate, so the 
> only question is where to put information about what to index. If I put 
> it in the domain, then some of those things will be there just because 
> the UI needs to query it. If I don't put it there it would have to be 
> done through other more cumbersome methods, and it won't be as easily 
> visible.
> 
> /Rickard
>

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

Re: Framework Annotations On Domain Objects

Hi Dan,

Yes, I actually expected you to be one of the first to comment :) but I appreciate you probably had to holiday
in Spain or some other comfortable place.

I will read over your blog posts.

Vaughn

--- In domaindrivendesign <at> yahoogroups.com, Dan Haywood <danhaywood@...> wrote:
>
> Hi Vernon,
> As you probably could anticipate, I'm a fan.
> 
> I actually blogged about this a month or so back (see 
> http://danhaywood.com/2009/11/11/annotations-vs-xml), distinguishing 
> annotations that are intrinsic to the domain layer with those that 
> provide semantics about adjacent layers.  So @Entity is in the former 
> camp, but @Table is in the latter.
> 
> For what it's worth, NO doesn't mandate annotations though - the 
> programming model can be changed to pick up the semantics from 
> wherever.  See the follow on post 
> (http://danhaywood.com/2009/11/12/overriding-annotations-with-a-dsl/) as 
> to how this is done.
> 
> Cheers
> Dan
> 
> PS: happy new year, everyone!
> 
> 
> 
> On 30/12/2009 00: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/properti es 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
> >
> >
>

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

A domain entity bridging two bounded contexts?

Hi all,

We have a pretty simple model that has until now been encapsulated in one bounded context, revolving around
content management (CMS). There was a user module but it was integrated into a  CMS module. Now we are
starting to refactor out the module to which it should belong, revolving around customer relations
(CRM). The problem is that there is a User object that has content and some functionality from the CMS
modules (folders, documents and queries), and also some from the CRM modules (questions,
authentication). These functionalities also work in the infrastructure against separate databases.

Our thought right now is to have two separate User objects, one aggregated by the other, basically a
UserWrapper and a UserInfo. The UserWrapper includes CMS functionality as well as exposing important
properties/functionality of the aggregated UserInfo object.

So getting a "User" object would entail sending the authentication information to the UserWrapper
repository, which would pass this on to the UserInfo repository, which would do its own authentication,
returning a UserInfo object to the UserWrapper repository. The UserRepository then performs its own
logic and returns a UserWrapper to the caller, which aggregates the UserInfo object.

This seems bizarre and unwieldy to me, but I don't have a better idea right now. It implies that an object in
one bounded context (UserWrapper in CMS) aggregates an object in another bounded context (UserInfo in
CRM). Does someone have a more elegant solution to this?

Infrastructurally, this object MUST be separate because I will have separate repositories for the
CRM-related functionality and the CMS-related functionality. 

Has anyone else had to deal with an object in one BC aggregating members in another BC? Like a User object
containing documents or the like?

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

Re: A domain entity bridging two bounded contexts?

On Sun, Jan 3, 2010 at 10:32 PM, jbenami1 <jbenami1 <at> yahoo.com> wrote:
>
>
>
> Hi all,
>
> We have a pretty simple model that has until now been encapsulated in one bounded context, revolving
around content management (CMS). There was a user module but it was integrated into a CMS module. Now we are
starting to refactor out the module to which it should belong, revolving around customer relations
(CRM). The problem is that there is a User object that has content and some functionality from the CMS
modules (folders, documents and queries), and also some from the CRM modules (questions,
authentication). These functionalities also work in the infrastructure against separate databases.
>
> Our thought right now is to have two separate User objects, one aggregated by the other, basically a
UserWrapper and a UserInfo. The UserWrapper includes CMS functionality as well as exposing important
properties/functionality of the aggregated UserInfo object.
>
> So getting a "User" object would entail sending the authentication information to the UserWrapper
repository, which would pass this on to the UserInfo repository, which would do its own authentication,
returning a UserInfo object to the UserWrapper repository. The UserRepository then performs its own
logic and returns a UserWrapper to the caller, which aggregates the UserInfo object.
>
> This seems bizarre and unwieldy to me, but I don't have a better idea right now. It implies that an object in
one bounded context (UserWrapper in CMS) aggregates an object in another bounded context (UserInfo in
CRM). Does someone have a more elegant solution to this?
>
> Infrastructurally, this object MUST be separate because I will have separate repositories for the
CRM-related functionality and the CMS-related functionality.
>
> Has anyone else had to deal with an object in one BC aggregating members in another BC? Like a User object
containing documents or the like?

It does sound bizarre and unwieldy :)

What is the need for combining these two roles into one?

--
Richard Dingwall
http://richarddingwall.name

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

The use of value objects

I am working on the design of a new system. Part of the model are customers, contracts, and estates. A
customer has one or more estates, a contract is an agreement with the customer to perform some kind of
service on one of the customer's estates.

Customer, Contract, and Estate will each be an aggregate root.

I am considering using Value Objects to handle the relation between the roots. E.g. I could use an
EstateDescription value object, the Customer object can have a list of EstateDescriptions, and the
Contract can have a single EstateDescription.

My idea here is that an EstateDescription can be instantiated much quicker than an Estate, and when working
with Customers or Contracts I really only care about the description.

Am I on the right track here?

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

Re: Enforcing the notion of aggregates.

In C#/.Net, an idea would be to put each root aggregate in a separate assembly, and make the constructors of
non root aggregate entities internal, thus only accessible via public methods in the factory.

--- In domaindrivendesign <at> yahoogroups.com, "Kenny" <ken.cochran@...> wrote:
>
> I've been trying to improve my understanding of aggregates and the role they play in DDD.
> 
> Boiling it down an Aggregate has the following properties:
> *Collection of related objects
> *Root - the "public face" of the aggregate, is always an entity
> 
> So in addition to its own data and logic the root also provides the sole means of accessing the other members
of the aggregate.
> 
> I'm wondering how to make the role of aggregate root more apparent. Naming conventions could serve has a
gentle reminder but how about something more enforceable?
> 
> A couple ideas that come to mind:
> 
> If supported by the language, nest all non-root classes within the root. This would allow the compiler to
enforce the aggregate's boundaries. The downside to this is the extra complexity it introduces into the
root. Even in languages that support partial class definitions this just seems clunky.
> 
> Another idea which sounds far more cumbersome is to require a reference to the calling object of the root's
type in all non-root objects' constructors and public methods. Again this would allow compiler
enforcement but is just riddled with problems and strikes me as a very bad idea.
> 
> Any other suggestions, comments, ranting welcome.
>

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

Re: The use of value objects

--- In domaindrivendesign <at> yahoogroups.com, "fklinteback" <fklinteback@...> wrote:
>
> I am working on the design of a new system. Part of the model are customers, contracts, and estates. A
customer has one or more estates, a contract is an agreement with the customer to perform some kind of
service on one of the customer's estates.
> 
> Customer, Contract, and Estate will each be an aggregate root.

How do you treat "Contract" is an aggregate root? Generally, contract will be create a new one instead of
change. Hope this article gives you idea : http://msdn.microsoft.com/en-us/magazine/ee236415.aspx

> 
> I am considering using Value Objects to handle the relation between the roots. E.g. I could use an
EstateDescription value object, the Customer object can have a list of EstateDescriptions, and the
Contract can have a single EstateDescription.
> 
> My idea here is that an EstateDescription can be instantiated much quicker than an Estate, and when
working with Customers or Contracts I really only care about the description.
> 
> Am I on the right track here?
>

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

Re: The use of value objects

Yes, the contract will only be changed if it was registered incorrectly, but to the contract different
tasks are attached, tasks that are done to fulfill the contract and they will change.

--- In domaindrivendesign <at> yahoogroups.com, "Limbu" <ichirohang@...> wrote:
>
> 
> 
> --- In domaindrivendesign <at> yahoogroups.com, "fklinteback" <fklinteback@> wrote:
> >
> > I am working on the design of a new system. Part of the model are customers, contracts, and estates. A
customer has one or more estates, a contract is an agreement with the customer to perform some kind of
service on one of the customer's estates.
> > 
> > Customer, Contract, and Estate will each be an aggregate root.
> 
> How do you treat "Contract" is an aggregate root? Generally, contract will be create a new one instead of
change. Hope this article gives you idea : http://msdn.microsoft.com/en-us/magazine/ee236415.aspx
> 
> 
> > 
> > I am considering using Value Objects to handle the relation between the roots. E.g. I could use an
EstateDescription value object, the Customer object can have a list of EstateDescriptions, and the
Contract can have a single EstateDescription.
> > 
> > My idea here is that an EstateDescription can be instantiated much quicker than an Estate, and when
working with Customers or Contracts I really only care about the description.
> > 
> > Am I on the right track here?
> >
>

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