Messages In This Digest (8 Messages)
- 1a.
- Re: Customizing a domain model From: Jørn Wildt
- 1b.
- Re: Customizing a domain model From: Casey Charlton
- 1c.
- Re: Customizing a domain model From: S Sobótka
- 1d.
- Re: Customizing a domain model From: Andreas Ohlund
- 1e.
- Re: Customizing a domain model From: Jørn Wildt
- 2a.
- Re: Repositories for lookups From: ryzamm
- 3a.
- Re: How do you plan your test From: Jonathan Harley
- 4a.
- SV: [domaindrivendesign] Persisting Value Objects (was: Re: Shared From: ryzamm
Messages
- 1a.
-
Re: Customizing a domain model
Posted by: "Jørn Wildt" jw@fjeldgruppen.dk jorn_lind_nielsen
Sat Sep 27, 2008 4:02 am (PDT)
> If they are let deep into your code base, then let them derive from your classes
> and pray they don't stuff you up
> - maintenance, upgrades, and stability become major issues.
All they are asking for now is to be able to add new fields, access them read/write through the database (outside our pogram), and see the values show up in the UI. So if we stick to that and ensure their fields are always prefixed with "xxx" then I assume we won't have any maintance problems. But then again, assumption is the mother of all failures :-)
Thanks for the response.
/Jørn
----- Original Message -----
From: Casey Charlton
To: domaindrivendesign@yahoogroups. com
Sent: Saturday, September 27, 2008 9:36 AM
Subject: Re: [domaindrivendesign] Customizing a domain model
I would probably defer to others on this as I have never found a "great" solution, becasue fundamentally this is a horrible thing to be doing.
If the customer is a "user" then a table of user defined fields, along with appropriate joins to the entites for their specific fields would be appropriate.
If the user is technical like you suggest, then it depends how close you are letting them get to your code. If they are let deep into your code base, then let them derive from your classes and pray they don't stuff you up - maintenance, upgrades, and stability become major issues.
If they are kept at arms length as they probbaly should be, then your services you expose to them (I would suggest only letting them interact via a services layer of some description) can hide your not ideal implementation, and make your contracts appear to them in a friendlier manner.
2008/9/26 Jørn Wildt <jw@fjeldgruppen.dk >
Does anyone have experience with customization of domain models (and, well, hmmm, entire applications)? I know "customization" is quite a broad term, so let me give an example: our customer wants to be able to extend the system we deliver. He wants to be able to add new customer-specific properties to some of the core entities, and he wants them to show up in the UI (but not necessarily automatically) . For instance, the entity Person could be extended with a new enumerated property "HairColor" which we haven't added to the system initially. The customer does not have write access to the application code, but he may freely depend on calling it from other applications.
We are using C#, NHibernate and Inversion of Control to model, persist and instantiate our bussiness objects, services and repositories.
In a system where only DataRows and DataTables are used, we can easily add extra columns without recompiling the code: just make sure to "select * from..." and all columns in the DB will be passed automatically to the UI (please ignore the perfomance problems with this).
But when we have hardwired Person as a class with N properties, how should the customer then extend it? How does a domain model handle that kind of feature request?
One solution is to let the customer inherit from Person to CustomPerson, extend it with the custom properties, and then inject new NHibernate mapping files and use IoC in configuration files to make sure all instances of IPerson are mapped to CustomPerson. But that is quite a lot more complex than simply adding a new field to the database - and requires the customer to be quite proficient with that setup.
Another solution is to store custom properties in a separate CustomPerson table and then do a "select *" from that table everytime we fetch a Person. The returned columns can then be added to the object Person as a referenced DataRow.
Other ideas?
Regards, Jørn Wildt
- 1b.
-
Re: Customizing a domain model
Posted by: "Casey Charlton" casey@goinsane.co.uk caseycharlton69
Sat Sep 27, 2008 5:25 am (PDT)
Well if they want to change the database ... You just need to change
your repository implementation to deal with entities that have a
dictionary for user defined properties as a child collection ... Messy
but ad good as anythin else I suspect
Casey Charlton
http://devlicio.us/blogs/ casey
On 27 Sep 2008, at 04:02, J©ªrn Wildt <jw@fjeldgruppen.dk > wrote:
> > If they are let deep into your code base, then let them derive
> from your classes
> > and pray they don't stuff you up
> > - maintenance, upgrades, and stability become major issues.
>
> All they are asking for now is to be able to add new fields, access
> them read/write through the database (outside our pogram), and see
> the values show up in the UI. So if we stick to that and ensure
> their fields are always prefixed with "xxx" then I assume we won't
> have any maintance problems. But then again, assumption is the
> mother of all failures :-)
>
> Thanks for the response.
>
> /J©ªrn
>
> ----- Original Message -----
> From: Casey Charlton
> To: domaindrivendesign@yahoogroups. com
> Sent: Saturday, September 27, 2008 9:36 AM
> Subject: Re: [domaindrivendesign] Customizing a domain model
>
> I would probably defer to others on this as I have never found a
> "great" solution, becasue fundamentally this is a horrible thing to
> be doing.
>
> If the customer is a "user" then a table of user defined fields,
> along with appropriate joins to the entites for their specific
> fields would be appropriate.
>
> If the user is technical like you suggest, then it depends how close
> you are letting them get to your code. If they are let deep into
> your code base, then let them derive from your classes and pray they
> don't stuff you up - maintenance, upgrades, and stability become
> major issues.
>
> If they are kept at arms length as they probbaly should be, then
> your services you expose to them (I would suggest only letting them
> interact via a services layer of some description) can hide your not
> ideal implementation, and make your contracts appear to them in a
> friendlier manner.
>
>
>
>
>
>
>
> 2008/9/26 J©ªrn Wildt <jw@fjeldgruppen.dk >
> Does anyone have experience with customization of domain models
> (and, well, hmmm, entire applications)? I know "customization" is
> quite a broad term, so let me give an example: our customer wants to
> be able to extend the system we deliver. He wants to be able to add
> new customer-specific properties to some of the core entities, and
> he wants them to show up in the UI (but not necessarily
> automatically). For instance, the entity Person could be extended
> with a new enumerated property "HairColor" which we haven't added to
> the system initially. The customer does not have write access to the
> application code, but he may freely depend on calling it from other
> applications.
>
> We are using C#, NHibernate and Inversion of Control to model,
> persist and instantiate our bussiness objects, services and
> repositories.
>
> In a system where only DataRows and DataTables are used, we can
> easily add extra columns without recompiling the code: just make
> sure to "select * from..." and all columns in the DB will be passed
> automatically to the UI (please ignore the perfomance problems with
> this).
>
> But when we have hardwired Person as a class with N properties, how
> should the customer then extend it? How does a domain model handle
> that kind of feature request?
>
> One solution is to let the customer inherit from Person to
> CustomPerson, extend it with the custom properties, and then inject
> new NHibernate mapping files and use IoC in configuration files to
> make sure all instances of IPerson are mapped to CustomPerson. But
> that is quite a lot more complex than simply adding a new field to
> the database - and requires the customer to be quite proficient with
> that setup.
>
> Another solution is to store custom properties in a separate
> CustomPerson table and then do a "select *" from that table
> everytime we fetch a Person. The returned columns can then be added
> to the object Person as a referenced DataRow.
>
> Other ideas?
>
> Regards, J©ªrn Wildt
>
> padding: 8px 0; } #ygrp-sponsor .ad #hd1{ font-family:
> Arial; font-weight: bold; color: #628c2a; font-size: 100%; line-
> height: 122%; } #ygrp-sponsor .ad a{ text-decoration: none; } #ygrp-
> sponsor .ad a:hover{ text-decoration: underline; } #ygrp-sponsor .ad
> p{ margin: 0; } o{font-size: 0; } .MsoNormal{ margin: 0 0 0 0; }
> #ygrp-text tt{ font-size: 120%; } blockquote{margin: 0 0 0
> 4px;} .replbq{margin:4} --> /html>
- 1c.
-
Re: Customizing a domain model
Posted by: "S Sobótka" slaweksobotka@yahoo.com slaweksobotka
Sat Sep 27, 2008 5:44 am (PDT)
Flexible attributes problem is desribed here: http://oreilly.com/catalog/ 9780596008673/
Solution is simple - a hash map.
So your data model would look something like this:
Enity (Person, whatever) ------< EntityValue >---------- Attribute
Attribute of course contains name and maybe type (ex. to determine valid values).
EntityValue - contains attribute, entity and value
Entity may ofcourse encapsulate deatils of hashMap implementation and contain "normal" accessors taht simply operate on inner hash map. (of course accesors are bad, but i mention it only if You really need them:).
In this approach you deal "standard" and "custom" attributes the same - as inner map in entity, so You can process them in the same coherent way.
But this is just the solution for data storing. Intuition tells me that project is convicted for failure. Because its just first illusion that attributes need only to be red and write. In future client will demnd business logic that process also custion attributes:P
Maybe "client extensible interface for scription languages" will discourage your client;)
cheers
slawek sobótka
- 1d.
-
Re: Customizing a domain model
Posted by: "Andreas Ohlund" andreas_ohlund@hotmail.com andreas_ohlund
Sat Sep 27, 2008 10:22 am (PDT)
Ayende has written a nice series of posts about multi tenancy that
might give you some ideas:
http://ayende.com/Blog/ archive/2008/ 08/16/Multi- Tenancy-- Approaches-
and-Applicability.aspx
--- In domaindrivendesign@yahoogroups. , Jørn Wildt <jw@...> wrote:com
>
> Does anyone have experience with customization of domain models
(and, well, hmmm, entire applications)? I know "customization" is
quite a broad term, so let me give an example: our customer wants to
be able to extend the system we deliver. He wants to be able to add
new customer-specific properties to some of the core entities, and he
wants them to show up in the UI (but not necessarily automatically).
For instance, the entity Person could be extended with a new
enumerated property "HairColor" which we haven't added to the system
initially. The customer does not have write access to the application
code, but he may freely depend on calling it from other applications.
>
> We are using C#, NHibernate and Inversion of Control to model,
persist and instantiate our bussiness objects, services and
repositories.
>
> In a system where only DataRows and DataTables are used, we can
easily add extra columns without recompiling the code: just make sure
to "select * from..." and all columns in the DB will be passed
automatically to the UI (please ignore the perfomance problems with
this).
>
> But when we have hardwired Person as a class with N properties, how
should the customer then extend it? How does a domain model handle
that kind of feature request?
>
> One solution is to let the customer inherit from Person to
CustomPerson, extend it with the custom properties, and then inject
new NHibernate mapping files and use IoC in configuration files to
make sure all instances of IPerson are mapped to CustomPerson. But
that is quite a lot more complex than simply adding a new field to
the database - and requires the customer to be quite proficient with
that setup.
>
> Another solution is to store custom properties in a separate
CustomPerson table and then do a "select *" from that table everytime
we fetch a Person. The returned columns can then be added to the
object Person as a referenced DataRow.
>
> Other ideas?
>
> Regards, Jørn Wildt
>
- 1e.
-
Re: Customizing a domain model
Posted by: "Jørn Wildt" jw@fjeldgruppen.dk jorn_lind_nielsen
Sat Sep 27, 2008 10:54 am (PDT)
> Intuition tells me that project is convicted for failure.
> Because its just first illusion that attributes need only to be red and write.
> In future client will demnd business logic that process also custion attributes:P
Yep, but that does not mean failure - that means future bussiness for us :-) But you are right about the warning and it needs special attention in the contract with the customer: what can they modify and how can they expect to do it.
Anyway, the hash/dictionary mapping is also a fine solution. The best about it is that it is actually modelled in the domain - not something which is added outside of the domain model later on. The backside is that you cannot simply add a new column to a database tabel and be done with it - but then, you cannot do that with the inheritance model I suggested either.
I'll take a look at the link. Thanks.
/Jørn
----- Original Message -----
From: S Sobótka
To: domaindrivendesign@yahoogroups. com
Sent: Saturday, September 27, 2008 2:44 PM
Subject: Re: [domaindrivendesign] Customizing a domain model
Flexible attributes problem is desribed here: http://oreilly.com/catalog/ 9780596008673/
Solution is simple - a hash map.
So your data model would look something like this:
Enity (Person, whatever) ------< EntityValue >---------- Attribute
Attribute of course contains name and maybe type (ex. to determine valid values).
EntityValue - contains attribute, entity and value
Entity may ofcourse encapsulate deatils of hashMap implementation and contain "normal" accessors taht simply operate on inner hash map. (of course accesors are bad, but i mention it only if You really need them:).
In this approach you deal "standard" and "custom" attributes the same - as inner map in entity, so You can process them in the same coherent way.
But this is just the solution for data storing. Intuition tells me that project is convicted for failure. Because its just first illusion that attributes need only to be red and write. In future client will demnd business logic that process also custion attributes:P
Maybe "client extensible interface for scription languages" will discourage your client;)
cheers
slawek sobótka
- 2a.
-
Re: Repositories for lookups
Posted by: "ryzamm" ryzamm@yahoo.com ryzamm
Sat Sep 27, 2008 7:53 am (PDT)
How about if i want to stick that State is a Value Object and i want
to store it to the State table itself. So when it comes to save into
the database who will take this responsibility? If i have Person
entity which is contain State Value Object does Person Repository do
the saving of State value? How about if i have more than one aggregate
entity refer to the same State value?
Thanks
- 3a.
-
Re: How do you plan your test
Posted by: "Jonathan Harley" jdharley@gmail.com agilista
Sat Sep 27, 2008 12:04 pm (PDT)
It depends what you already have; how far into the project you are.
Before you write any code, write a test. I generally start with the
higher level classes and work my way down. The main thing is to make
sure that you only test the class you are working on and mock or stub
the rest (unit test).
Integration tests cross boundaries; make sure they are separated from
your unit tests or you will end up waiting for things like databases
to respond (you don't need to test the database, do you? If you feel
you have to, maybe you should consider another database). If you do
significant work cross boundaries, run the integration tests.
Finally, get a coverage analyzer and use it. Make no excuses and get
100% coverage of all your code. Yes, even accessors. Once you get
used to seeing a full green bar on your tests and your coverage you'll
feel confident that you can refactor at will. 100% isn't the
be-all-and-end-all either, make sure you are testing positive and
negative outcomes.
I hope this helps - Jon
On Sat, Sep 27, 2008 at 12:43 AM, Casey Charlton <casey@goinsane.co.uk > wrote:
> Start with the user story (or requirement) ...
>
> "As a user I want to search for keywords"
>
> First test is one that takes some keywords, creates a SearchService
> instance, calls the GetSearchResultsFor(searchTerms) , and verifies it
> doesn't throw. (red)
>
> Now create the SearchService, give it a method GetSearchResultsFor, and
> return and empty list. (green)
>
> And from there you drive the rest of the tests out through this one single
> path through your application layers.
>
> - pass null searchTerms, assert if throws an appropriate exception
> - pass empty searchTerms, assert it returns all records (at this point you
> need to give the SearchService some kind of data source, probably in its
> constructor, which you then fake or mock)
> - pass specific searchTerms, assert it returns only items matching
>
>
> And so on ....
>
>
>
> 2008/9/26 ryzamm <ryzamm@yahoo.com >
>>
>> Hi all
>>
>> I want to know the good approach when come to start TDD in DDD, do you
>> start your test from ApplicationServices layer or do you start the
>> test in the domain first? For example you may create TestOrderService
>> and then from that it will drive until to domain layer or the test
>> focus directly to domain meaning that you will have TestOrderDomain
>>
>
>
--
A long habit of not thinking a thing wrong, gives it a superficial
appearance of being right, and raises at first a formidable outcry in
defense of custom.
-Thomas Paine
- 4a.
-
SV: [domaindrivendesign] Persisting Value Objects (was: Re: Shared
Posted by: "ryzamm" ryzamm@yahoo.com ryzamm
Sat Sep 27, 2008 5:54 pm (PDT)
For me we can have a few option when comes to design Value Object
First we focus on Shared Value Object.
The first rule need to follow is to make sure Shared Value Object is
immutable, let say for example in Person/Address scenario. Person A
has reference to Address1 value object and Person B also has reference
to Address1 value object meanwhile Person C has reference to Address2.
After a few months Person B move out from the Address1 to Address2, we
can change the Person B address to refer to Address2 but how about if
the Person B move to new address Address3? because Address is value
object we cannot change/update the value of Address1 to Address3
instead we create new instance of Address3 and make Person B refer to
that value object. So if we talk about data in Address table we will
have 3 value - Address1,Address2 and Address3.
--- In domaindrivendesign@yahoogroups. , don@... wrote:com
>
> I don't really understand what the problem with shared value objects
is.
>
> @Matthias: i can insert millions of equal value objects at the same
time.
> That's the purpose of VOs.
>
> Let's take the address example and the delete problem:
> If one address is deleted, changed etc. it would be invalid or not
existent
> anymore to others who share it.
>
> Well, you could solve this by e.g. observers or other technical
things.
> A real life example: you tell somebody your address has changed.
> Now he changes his records or he doesn't, so the address stays the
same.
> But in DDD it is furthermore a valid address (vo). It's your problem
what
> your database consistency says.
>
> Another example would be the address is invalid because someone
moved away.
> If he doesn't tell anybody else, all others would have the old
address.
> But that's not the problem of the addresse it's one of communication
and when
> and how you check your value objects for validity/existence.
>
> This real-life examples aren't the problems of value objects but of
> your application or the persistence.
>
> Am I completely wrong?
>
> Cheers,
> Nino
>
> ========== Urspr. Mitteilung ==========
> Von: domaindrivendesign@yahoogroups. com
> An: domaindrivendesign@yahoogroups. com
> Datum: Thu, 24 Jul 2008 11:02:06 +0200
> Betreff: Re: SV: [domaindrivendesign] Persisting Value Objects (was:
Re: Shared value object implementation?)
>
> How do you make sure in your application, that value objects are not
shared?
>
> One could implement something like:
>
> // Address is an value object
> person2.setAddress(person1.getAdres se());
>
> I see another problem of shared value objects: If two transactions
try to insert equal value objects at "the same time" in two different
transactions - you may end up with duplicated records or with an
exception if you have an unique constraint on your database table.
>
> Kind regards
>
> Matthias.
>
>
>
> ----- Original Message ----
> From: Tomas Karlsson <tomas.lg.karlsson@...>
> To: domaindrivendesign@yahoogroups. com
> Sent: Wednesday, July 23, 2008 8:54:30 PM
> Subject: SV: [domaindrivendesign] Persisting Value Objects (was: Re:
Shared value object implementation?)
>
>
> I strongly recommend you NOT to share value objects between
> different owning entities. It can be a nightmare when you start to
delete
> data... Remember that a value object in a UML class diagram always
has a strong
> aggregate to the owning entity, and therefore sharing value objects
introduces a
> very strange feature in the implementation - something that is not
present in
> the domain model.
>
> The reason why I write 'NOT' is because I have really
> bad project experience with Java/Hibernate on how complex things can
be if value
> objects are shared when they have the same value.
>
> /Tomas
>
>
> _____________________ _________ __
> Från: domaindrivendesign@ yahoogroups. com
> [mailto:domaindrive ndesign@yahoogro ups.com] För matthias.kampen
> Skickat: den 23 juli 2008 17:28
> Till: domaindrivendesign@ yahoogroups. com
> Ämne: [domaindrivendesign ]
> Persisting Value Objects (was: Re: Shared value object
> implementation? )
>
>
> Hello,
>
> if you have an entity which holds a collection of value objects
> - how
> do you persist such a collection using hibernate/jpa?
>
> Are you
> persisting them shared (multiple persisted entities may point
> to the same
> persisted value object record) or separate for each entity
> (this may
> generates multiple database records for the "same" value
> object)?
>
> Kind
> regards
>
> Matthias
>
> --- In domaindrivendesign@ yahoogroups. com,
> "Pascal Lindelauf"
> <pascal@> wrote:
> >
> > With a friend
> and collegue of mine I was discussing the usage of value
> > objects vs.
> entity objects. The concepts are clear to us, but one thing
> > that stuck
> around is the whole immutability aspect; especially when the
> > desire for
> sharing immutable value objects pops up. We were just
> > wondering how
> anyone would implement this neatly in the domain. As far
> > as I'm
> concerned, sharing immutable value objects is a typical
> >
> implementation/ architectural decision, which has nothing to do with
> the
> > business domain. So the last thing I would want is to litter my
> domain
> > code with things like finding a value object that matches
> my
> > requirements and if it doesn't exist: create a new value
> object.
> >
> > I'm thinking that would look something like this
> (highly
> > simplified!) :
> >
> > public class Money
> >
> {
> > private string currency;
> > private decimal amount;
> >
> > public static Money Add(Money m1, Money m2)
> > {
> > // Let's
> assume the same currency here
> > Money tempResult = new Money(m1.currency,
> m1.amount + m2.amount);
> >
> > // Returns an already existing money
> object that equals
> tempResult,
> > or else
> > // it registers
> tempResult (for sharing by others) and returns it.
> > return
> MoneyRepository. GetSharedObject( tempResult) ;
> > }
> >
> }
> >
> > Assuming this is still okay-ish, then what happens if more
> value objects
> > get loaded from the database, e.g. through (N)Hibernate?
> Now we will
> > have to write code additional code in the repository around
> the default
> > NHibernate mechanism that loads value objects. This starts
> to get smelly
> > in my opinion.
> >
> > Anyway, I'm very curious
> if there's anyone who has implemented
> > an elegant shared value object
> mechanism and what it looks like. Care to
> > share?
> >
> >
> Pascal.
> >
>
Need to Reply?
Click one of the "Reply" links to respond to a specific message in the Daily Digest.
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Individual | Switch format to Traditional
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
0 comments:
Post a Comment