domain modeling naming problem

views:

answers:

domain modeling naming problem

Hello

There are some simple entities in an application (e.g containing only id and title) which rarely change and are being referenced by the more complex entities of the application. These are usually entities such as Country, City, Language etc.

How are these called? I've used the following names for those in the past but I'm not sure which is the best way to call them:

reference data
lookup values
dictionaries

thanks

+2 A:

I would say Reference Data

See link text

djna 2010-06-02 06:28:18

Thanks. Any reference/documentation on that?

cherouvim 2010-06-02 08:07:32

Reference Data it is then. Thanks

cherouvim 2010-06-03 05:12:00

+2 A:

You tagged with "ddd", so assuming that you are looking for a more Domain-Driven Design approach, drop the identifier on these objects and treat them like Value Objects.

The reason you might consider dropping the identifier is that it adds unneeded complexity to the problem domain. For example, you have a "Country" table in your implementation, I am assuming? You would still have it, but it wouldn't be a referential lookup. You would use it purely as "reference data". Load it upfront for scenarios where it needs to be referenced - maybe your UI is binding it to a dropdown list, for example...

When the entity is saved or updated, you store the value of the object, hence the "value" "object". If the user changes the entity for another value, no problem, just update the value. It is one less associative lookup that has to be made when doing CRUD operations, which makes the overall model less complex.

joseph.ferris 2010-06-02 19:12:27

Thanks. Yes, I've read about Value Objects in http://amzn.com/0321125215 . It's an interesting concept, but in a db level doesn't it look like denormalization? The country literals will be scattered all over the place. More importantly, when I need to change a country text (e.g a typo) I'd have to scan many tables to apply the fix.

cherouvim 2010-06-03 05:06:17

@cherouvim - One of the keys to DDD is that it does not matter what the database looks like, as long as you have a reliable mapping layer between you entities and your data. As for the typos, you are correct. You would have to look multiple places to make a fix. From a management aspect, you could always maintain a stored procedure to update every instance of it, though. For example, you could have a stored proc to update all of your country references that takes the old and new value as parameters and executes the update statements for you, so you only have to call one proc to fix it.

joseph.ferris 2010-06-03 07:35:17

(continued) Arguably, though, having to change existing values is really an edge case. The frequency that you would need to do it would be very low and, since this data is fairly static, you should have these sort of issues sorted out before your code becomes "production quality". The book you reference is the "Blue Bible" - the same place the definition on the link I provided came from. :-)

joseph.ferris 2010-06-03 07:37:42

@joseph.ferris: makes sense, thanks for the data. Stored procedures, though, are a showstopper for my case.

cherouvim 2010-06-03 08:00:31

ansaurus

tags:

views:

answers:

domain modeling naming problem

related questions