Okay.  If you are referring to the maintenance of value objects then,
for the purpose of maintenance, do we temporarily treat the value
objects (in any other context) as entities?  I think this a reasonable
variation, and not incorrect given the context.

Context is everything.

On Sun, Sep 28, 2008 at 12:39 PM, ryzamm <ryzamm@...> wrote:
> I think we need to separate Value Object to 2 types. One is initial
> list value object and another one is runtime value object (i'm not
> sure the term is correct or not).
>
> Let's take initial list value object concept. Initial list value
> object is like a data to represent in lookup/dropdownlist, for example
> country. We need to create a value object for all valid country in the
> world
> 1. United State
> 2. China
> 3. Russia
> 4. ...
>
> So the question comes to whom the managing responsibility should we
> put? Do we need to have GenericAdmin repository or GenericValueObject
> repository for maintenance?
>
> Another type of value object is a runtime value object meaning that we
> only create new instance when needed. For example Person entity and
> Address value object. Normally we don't put address in dropdownlist
> for client to select the address . Person A have reference to AddressA
> and then PersonB join to live in the same address, if we want to add
> PersonB address, we should check if the value we add already exist or
> not if yes we just make a reference AddressA to PersonB but if Person
> B live next to PersonA, so when we check the address value no value
> equality exist then we will create a new instance of AddressB and set
> a reference for PersonB.I think for the second type quite clear the
> saving value object will be responsible by the entity who use that
> value object. Type 1 still not clear to me
>
> --- In domaindrivendesign@yahoogroups.com, "Jonathan Harley"
>
> <jdharley@...> wrote:
>>
>> The class that uses the value object stores its reference via the
>> repository for the using object.
>>
>> On Sat, Sep 27, 2008 at 7:53 AM, ryzamm <ryzamm@...> wrote:
>> > 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
>> >
>> >
>>
>>
>>
>> --
>> 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
>>
>
>



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

Forgetting the implementation details for the moment to do it in a
sophisticated way what you need is to have a "metadata" component of
your domain model.  If the user has to be able to add attributes to
entity types then you will need an object "entity type" in your
metadata model and will methods like 'add attribute".   If the user
has to be able to add fields to screens then you will the screens
will have to be objects in the metadata model.  The you will need to
figure out what sort of user interface to use that allows the user to
update the metadata.

There are many details to work out and it all depends on the level of
sophistication your requirements and budget allow for.    If you
customization requirements are limited a shortcut frequently used is
just to build in a few user defined fields into your database "e.g.
userfield1, userfield2, etc". and then just let the user have the
ability to change field labels.

As far as storing the data is concerned a lot depends on what the
user needs to do with the data outside of your application.  They may
require a particular structure to make it easy to your data with
legacy applications.    If they don't need to access the data outside
your applications API then XML is an elegant to way to store user
defined fields but there are many other choices.

Bill



--- In domaindrivendesign@yahoogroups.com, Jørn Wildt <jw@...> wrote:
>
> 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
>

In this kind of scenario I usually have a state machine on the class.
  Simple states would do

Creating,
Live

Some constraints are added if the state == Creating (Name required,
Name must be unique, etc), additional constraints are added if the
state == Live.


Pete
====
http://mrpmorris.blogspot.com
http://www.capableobjects.com

My rule is simple.

"Can the child exist without the parent?"

[Order] (Order) 1---* (Lines) [OrderLine]

If you delete the Order then its lines should also be deleted, it
makes no sense to have lines exist without an order.


[Country] (CountryOfResidence) 1--* (Residents) [Person]

Here I would use aggregation (prohibit delete) because deleting a
country should not delete lots of people, you would obviously be
deleting a country entered in error or something so you would want the
delete to fail if someone had assigned residents to it.


Pete
====
http://mrpmorris.blogspot.com
http://www.capableobjects.com

For me there are two types of "Can I" on an object

01: Is it logical for this object to perform this task based on its state.
02: Is it permissible for the current user to perform this task.

The framework I use abstracts all of its services and provides access
via a service provider pattern.  I find this useful for many reasons
that I wont go into because I tend to talk too much :-) but one of the
advantages is that it allows you to register your own services.

Coincidentally I blogged about unit testing security only a few days ago.
http://mrpmorris.blogspot.com/2008/09/unit-testing-security.html


Pete
====
http://mrpmorris.blogspot.com
http://www.capableobjects.com

Hello Jørn,

This is a typical "have your cake and eat it" scenario that customers
think they'll need.  It ends up being utterly dumb data and as soon as
your system (er... domain) requires knowledge of it in any way, manner,
or form, then it absolutely has to move into the domain.  This
typically happens when business rules enter the fray.

If, however, you can treat treat the data as dumb I would create a sub-
domain (is this right?).  I don't know if your core domain even need be
aware of this.  Your front end sure would.

So you have a Person.  Now your generic mechanism doesn't care what the
data belongs to.  It simply contains the ID (guid is nice, heh?), the
type (or type name) --- Hair Colour, etc. --- and the value.  This can
then be managed totally separate from your core domain without
resorting to the likes of "select *".

Regards,
Eben

I prefer explicitly Specifying validity context, I usually separate
IsValid from IsValidForPersistence, thus the infrastructure would
allow saving of entity by just checking IsValidForPersistence,
otherwise business validity will be done by checking IsValid.

thus i have 2 methods: GetBrokenRules(), and
GetPersistenceBrokenRules() where GetBrokenRules cares about business
validity, also we can make variation like
GetBrokenRulesForTransitionTo(State) for checking state based business
rules validity, the other method GetPersistenceBrokenRules() will
return a list of broken rules that prevents object from persistence.

--- In domaindrivendesign@yahoogroups.com, "Scott Millett" <scott@...>
wrote:
>
> Thanks for the suggestion. I have changed my model so that a Solution is
> always created for each problem, this solution has a category which is
> an enumeration and by default is set to Model.SolutionCategory.NotSet. I
> can then check for this in my broken rules to check if I can or cannot
> save the entity.
>
>
> Public Class Solution
>
>          ' Default the SolutionCategory to 'NotSet'
>          Private _SolutionCategory As SolutionCategory =
> Model.SolutionCategory.NotSet
>          Private _SolutionSteps As List(Of SolutionStep)
>
>          ' Constructor...
>          ' Other Properties/Methods...
>
>           Public Property SolutionCategory() As SolutionCategory
>                  Get
>                            Return _SolutionCategory
>                  End Get
>                  Set(ByVal value As SolutionCategory)
>                           _SolutionCategory = value
>                  End Set
>            End Property
>
>            Public Function GetBrokenRules() As List(Of BrokenRule)
>                 _BrokenRules.Clear()
>
>                 If SolutionCategory = Model.SolutionCategory.NotSet _
>

> And _SolutionSteps.Count > 0 Then
>                           ' We must have a solution category before
> adding solution steps
>                           ' as depending on the solution specified
we may
> have other specifications
>                           ' that need to be satisfied
>                          _BrokenRules.Add(New BrokenRule _
>                                             ("You must select a solution
> category if you are adding solution steps."))
>                 Else
>
>                        For Each ss As SolutionStep In _SolutionSteps
>                                ' A solution step will only check for
> broken rules if it
>                                ' is complete i.e. we can save steps that
> are in progress
>                                ' this is checked in the step entity
>                                If ss.GetBrokenRules.Count > 0 Then
>                                          For Each br As BrokenRule In
> ss.GetBrokenRules
>                                                   _BrokenRules.Add(br)
>                                           Next
>                                End If
>                        Next
>                  End If
>
>                  Return _BrokenRules
>         End Function
> End Class
>
> Public Class Problem
>
>         Private _Solution As Solution
>
>         Public Sub New()
>                  _Solution = New Solution
>         End Sub
>
>         Public ReadOnly Property Solution() As Solution
>                Get
>                         Return _Solution
>                End Get
>         End Property
>
>         ' Other Properties/Methods...
>
>         Public Function GetBrokenRules() As List(Of BrokenRule)
>             _BrokenRules.Clear()
>
>             If Solution.GetBrokenRules.Count > 0 Then
>                   ' For Each Broken Rule in the Solution add it to the
> list of broken rules
>                   For Each BRule As BrokenRule In
Solution.GetBrokenRules
>                            _BrokenRules.Add(BRule)
>                   Next
>             End If
>
>             If String.IsNullOrEmpty(Problem) Then
>                  ' No Problem, we can't let the user save
>                 _BrokenRules.Add(New BrokenRule("No Problem Defined"))
>             End If
>
>             Return _BrokenRules
>         End Function
>
> End Class
> Do you think this design has any major flaws?
>
> Thank you for bearing with me I am learning lots :0)
>
> --- In domaindrivendesign@yahoogroups.com, "matthias.kampen"
> <matthias.kampen@> wrote:
> >
> >
> >
> > --- In domaindrivendesign@yahoogroups.com, "Scott Millett" scott@
> > wrote:
> > >
> > >
> > > Ok I see what you mean about having my business rules being applied
> > > dependant on the state of the problem entity, were you thinking
> along
> > > the lines of something like this:
> > >
> >
> > I would try to get one step further: It should be impossible to reach
> > a certain state as long as there are broken rules. So you might check
> > the rules on state transition and throw an exception when a broken
> > rule appears.
> > After reaching a certain state it should either be impossible to break
> > the required rules (for this state) or the state should change as soon
> > as a borken rule appears.
> >
> > >
> > >
> > > Public Function GetBrokenRules() As List(Of BrokenRule)
> > >
> > > _BrokenRules.Clear()
> > >
> > > Select Case _ProblemState
> > > Case ProblemState.New
> > >
> > > If String.IsNullOrEmpty(Problem) Then
> > > _BrokenRules.Add(New BrokenRule("No
> > > Problem Defined"))
> > > End If
> > >
> > > Case ProblemState.SolutionSelected
> > >
> > > ' We would only check for broken rules on the
> > > parts of the solution
> > > ' that were set as complete
> > > For Each BRule As BrokenRule In
> > > Solution.GetBrokenRules
> > > _BrokenRules.Add(BRule)
> > > Next
> > >
> > > End Select
> > >
> > > Return _BrokenRules
> > > End Function
> > >
> > > Thanks for your help.
> > > Scott
> > >
> > > --- In domaindrivendesign@yahoogroups.com, "matthias.kampen"
> > > <matthias.kampen@> wrote:
> > > >
> > > > It looks like in your domain Problem-Entity is completely valid
> even
> > > > though there are broken rules (a Problem without complete Solution
> is
> > > > a valid domain object).
> > > >
> > > > I think you should try to implement your entities in a way that
> they
> > > > are always in valid state and separate validity from possible
> > > > object-states.
> > > >
> > > > On the other hand you may implement a Specification which checks
> > > > whether a Problem can be saved or not.
>

--- In domaindrivendesign@yahoogroups.com, "Scott Millett" <scott@...> wrote:
>
>
> I have a Problem entity that may have a Solution entity related to it.
> The Problem entity can be persisted before a solution is assigned to it.
> I would like to be able to save the Problem entity before the solution
> entity is complete as the solution may be completed in steps over some
> time. How do I show that the Solution is not complete (via a collection
> of broken rules) but still allow the entity to be saved? [...]

Scott,

I'm just a newbie, but might I suggest that the Route Specification and
Itinerary example
in the Ubiquitous Language section of Evan's book is an example of this
scenario.  It has
the subtitle 'Scenario 2: Domain Model Enriched to Support Discussion'

In that example there is a Route Specification and an Itinerary that must
satisfy that
specification.  When the itinerary is updated then a routing service reviews the
modified
instance against the specification and is responsible for taking any necessary
follow up
actions.

In your example you could take a similar approach and separate the rules into a
specification object with a service to manage it's relationship with the value
object.

Regards,


Ged Byrne
www.rushcoding.co.uk

[my google-fu has failed me. if the answer exists elsewhere, please
point me to it. thanks]

We our dipping our toes into the domain driven waters and have some
newbie questions.

Setting the scene - we have a farm of stateless web servers and our
domain has (will have) fairly complex aggregates that potentially take
up a fair amount of memory and are quite expensive to load from the
database.

[sanitizing the domain a little for confidentiality reasons]

A User has a Plan which has Rules and History and Periods and a whole
bunch of other things that needn't concern us right now - but there
are a lot of them.

Plan seems like a natural aggregate root and I'll assume a
PlanRepository with a findPlanFor(user) method. I get to all the other
entities via the Plan. So far so good?

Here's my question:

Most User interactions with the Plan are read-only and deal with a
tiny slice of the plan. How should I deal with this?

It's not practical to read the entire aggregate (it's too big) so I am
assuming some kind of lazy loading should happen. I am imagining
something like this

Plan.GetHistory(from, to) (or some variant of this using specifications)

but what happens next?

I'd assume the Plan has a reference back to its repository for
Lazy-Loading purposes, but then the repository has to expose a bunch
of methods for low-level queries on non-root entities.

Maybe that's OK? Would you model this differently?

And a more general question - can anyone point me to a write up (or
share experience about) a similar situation viz.
highly-scalable/web-farm using DDD?

Thanks in advance,

Kevin

--- In domaindrivendesign@yahoogroups.com, "Paul Batum" <paul.batum@...> wrote:
>
> [...] When it comes to
> determining whether cascades occur across a particular relationship,
> do you ever have to make an independent decision, or do you just have
> a simple rule that will always tell you what to do? The rule I'm
> currently imagining is: Always and only enable cascades from each
> aggregate root through to all of its leaves. [...]

Hello,

I'm new to the group and still only quarter of a way through the book, so I can
only answer
from my own experience.  My apologies it isn't considered a useful contribution.

My rule of thumb is that cascades are related to identity.  By identify I mean
the key that is
used to access the entity.  If an entity is deleted then everything that is
identified with that
identify is also deleted.

However, I probably would want to leave cross aggregate deletions to the ORM. 
When this
happens you probably want to be able to hook events at a business level.

What I do now is use an effective dating pattern (1) to deal with
cross-aggregate
relationships, so that this scenario is a matter of superceeding the previous
instance
rather than deleting it.  This approach simplifies a lot of the concerns about
when objects
should be destroyed, but it is difficult for people to understand and make
querying the
database a nightmare.  I'm also starting to worry about the implications for
archiving data.

From what I have read so far, I would say that any situations that leads to the
need for a
cross aggregate deletion should be handled by a separate policy and that the
aggregate
boundaries should be reviewed because of the awkwardness of the design.

I present my current thinking in the hope that it may be useful and also to see
how that
thinking might change with practicing domain driven design.  I appreciate any
feed back.

Thanks,


Ged Byrne
www.rushcoding.co.uk

(1) http://martinfowler.com/ap2/effectivity.html

Remember that aggregate boundaries are a modeling choices, and they
are coevolving with the other modeling choices, such as which classes
you want and which relationships. There are many, many possible
models, and if the one you have chosen is not serving you well, start
brainstorming to find another one.

You mentoned that the Plan seems like a 'natural aggregate root' and
that you have a lot of things tied to it. That naturalness is the
place to start, but the decision is more based on the intended usage
of the model.

If most of the usage involves a 'tiny slice of the plan' then my first
thought is that Plan, in your current conception, is too monolithic.
Look for coherent concepts that could give smaller meaningful slices.
'Why are people interested in this particular slice?', I might ask.
Does that slice have some significance? Could there be a concept there
to pull out (which might be a new aggregate root, or might just be a
stepping stone in that direction)?

On the other hand, read-only use-cases are not very demanding in terms
of aggregate modeling. If your big Plan is serving you well in the
scenarios where state is changing, then it isn't so bad to just not
load (lazy load) the parts you are not going to look at in a
particular case.

Eric

--- In domaindrivendesign@yahoogroups.com, "Kevin Lawrence"
<kev.lawrence@...> wrote:
>
> [my google-fu has failed me. if the answer exists elsewhere, please
> point me to it. thanks]
>
> We our dipping our toes into the domain driven waters and have some
> newbie questions.
>
> Setting the scene - we have a farm of stateless web servers and our
> domain has (will have) fairly complex aggregates that potentially take
> up a fair amount of memory and are quite expensive to load from the
> database.
>
> [sanitizing the domain a little for confidentiality reasons]
>
> A User has a Plan which has Rules and History and Periods and a whole
> bunch of other things that needn't concern us right now - but there
> are a lot of them.
>
> Plan seems like a natural aggregate root and I'll assume a
> PlanRepository with a findPlanFor(user) method. I get to all the other
> entities via the Plan. So far so good?
>
> Here's my question:
>
> Most User interactions with the Plan are read-only and deal with a
> tiny slice of the plan. How should I deal with this?
>
> It's not practical to read the entire aggregate (it's too big) so I am
> assuming some kind of lazy loading should happen. I am imagining
> something like this
>
> Plan.GetHistory(from, to) (or some variant of this using specifications)
>
> but what happens next?
>
> I'd assume the Plan has a reference back to its repository for
> Lazy-Loading purposes, but then the repository has to expose a bunch
> of methods for low-level queries on non-root entities.
>
> Maybe that's OK? Would you model this differently?
>
> And a more general question - can anyone point me to a write up (or
> share experience about) a similar situation viz.
> highly-scalable/web-farm using DDD?
>
> Thanks in advance,
>
> Kevin
>

----- Original Message -----

From: Tomas Karlsson

To: domaindrivendesign@yahoogroups.com

Sent: Sunday, October 05, 2008 3:58 PM

Subject: SV: [domaindrivendesign] Customizing a domain model

Today, we are often using looser typing of the domain model. But only for the attributes that do not affect business logic. Simply a key/value construction where one is allowed to add the key "HairColor" and any value. If you want an enumeration, add an enumeration construction as well. Easy to implement both directly in SQL databases and in some generic subdomain.

 

However, for us these models work fine as long as automated processes, that is code, populates and reads the model. We often talk about a contract between the producer and consumer of the information while the persistent storage and transport layers don't have to know (and act one) the exact meaning of the information.

 

We have also found that user interfaces normally fail to be extendable in such situations. The requirements on usability are so high today som users don't accept something bad generated thing coming from these key/value and enumeration constructions in the domain model.

 

/Tomas 

---

Från: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] För Stefan Moser
Skickat: den 27 september 2008 00:12
Till: domaindrivendesign@yahoogroups.com
Ämne: Re: [domaindrivendesign] Customizing a domain model

I worked on a project with similar requirements in the past.  One question you have to ask yourself is does any *logic* change with any of these customization properties. 

 

Here is an example.  Let's say that your application manages parties (the ones with food and drinks and fun) and a major part of your domain is tracking how much fun a person is having.  So you have a Person entity.  Now one of your customers wants to customize the application to add HairColor to the Person entity.  Are they also able to change the *logic* within the Person entity so that when HairColor == HairColor.Blonde that they can also say Fun++?  Sorry, I just couldn't resist. :-)

 

But seriously, it is rarely the case that these kinds of applications allow the customization to have any effect on business logic.  If this is the case, you're basically dealing with this part of the application being simple forms over data.  One way that this can be handled is to not change the core Person in anyay, but to decorate the Person outside of the domain boundaries.

 

Depending on the complexity of your customization requirements, this could become its own pseudo bounded context.  The one I worked on actually had a fair amount of logic in how the customization was set up.

 

The project started with the "let's just extend the database tables" approach, but this caused ssssooooo many problems that I would recommend not going down that route at all.

 

I know it's vague, but hope that helps a little.

 

Stefan

On Fri, Sep 26, 2008 at 2:20 PM, Jørn Wildt <jw@fjeldgruppen.dk> wrote:

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

----- Original Message -----

From: Tomas Karlsson

To: domaindrivendesign@yahoogroups.com

Sent: Sunday, October 05, 2008 10:04 PM

Subject: SV: [domaindrivendesign] Customizing a domain model

Hi,

 

Interesting comment on reporting! It will help me in the design of the system I am working on now. We are actually thinking of duplicate models: one DDD model for production of data and one data warehouse model (a relational database 'star') for analysts. I have found out from earlier projects that it can be conflicts if the two approaches are implemented in the same model.

 

We have recently integrated Ruby scripts in Java using the javax.scripting. (I have not written the code, but I know all business needs and details.) Maybe a pluggable Ruby script can be used for validation of the key/value attributes? You define a new attribute by defining a key, one of a set of basic data types (int, float, boolean, and the general String) and an optional Ruby script for validation. We have used Ruby as a light-weight rule engine - and it looks very promising. (By the way, are you using Java? I suppose .NET has some similar connection to scripting languages...)

 

The alternativ is, of course, to define the key as an enumeration and provide a list of valid values. No Ruby script for validation is needed in that case. (By the way, that is also true for booleans..)

 

Adding the 'valid from' and 'valid to' properties on the key definition seems to be a trivial extension.

 

More complex extensions can, of course, be implemented using interfaces with methods like onNewAttribute(value) - with one implementation class per added attribute. However, it is always difficult to have pluggable compiled code. (We have pluggable Java code where we actually upgrade plugins without stopping the JVM by adding the version to the full class name.) Pluggabe scripts are easier, but such code still makes me unhappy: It is to difficult for a customer to understand when their code is triggered and to find something meaningful to do. And I think brilliant and complex solutions should be avoided :-)

 

/Tomas

---

Från: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] För Jørn Wildt
Skickat: den 5 oktober 2008 20:45
Till: domaindrivendesign@yahoogroups.com
Ämne: Re: [domaindrivendesign] Customizing a domain model

Hi Thomas

 

> We have also found that user interfaces normally fail to

> be extendable in such situations. The requirements on 

> usability are so high today som users don't accept

> something bad generated thing coming from these

> key/value and enumeration constructions

 

Yes, it ain't really an easy requirement. Mentally I have begun to work with two different extension models, each of which is more complex than the other, but also fullfills more requirements.

 

I think we will go with the key/value approach. With this approach we actually put the extra properties inside the core domain model as simple extra attributes on entities. Just as many people here has suggested. I am pretty sure this can be implemented in a generic way, such that it will be easy to add attribution to any core entity.

 

Since we now have these in the domain model, we can also make use of that in various (developed in-house) reporting tools that can be made attribution aware, such that it will be possible to filter by the attributes and display them.

 

And, yes, that leaves the UI with a simple list of key/values (with proper input validation). But I can easily imagine a situation where our customer suddenly needs to register X (maybe only for a short period), but we don't have time in our schedule to implement it for them. Then it's good for them to know that 1) it will be possible, and 2) they can export and report based on those attributes.

 

But all that only helps with the basic customer scenario. Besides this we have a vision of making a product that others can extend and customize. This leaves us with many many more requirements besides adding extra properties: adding custom reports, adding extra sub-applications, customizing existing bussiness rules and so on.

 

In this more complex case I think it is better to allow a partner to extend our core entities with the own properties and use IoC to make sure the application works on the extended entities.

 

I am quite confident that it is possible - but time will show if it also feasible and gets adapted by others.

 

Thanks for all the interesting replies so far.

 

/Jørn 

 

 

----- Original Message -----

From: Tomas Karlsson

To: domaindrivendesign@yahoogroups.com

Sent: Sunday, October 05, 2008 3:58 PM

Subject: SV: [domaindrivendesign] Customizing a domain model

Today, we are often using looser typing of the domain model. But only for the attributes that do not affect business logic. Simply a key/value construction where one is allowed to add the key "HairColor" and any value. If you want an enumeration, add an enumeration construction as well. Easy to implement both directly in SQL databases and in some generic subdomain.

 

However, for us these models work fine as long as automated processes, that is code, populates and reads the model. We often talk about a contract between the producer and consumer of the information while the persistent storage and transport layers don't have to know (and act one) the exact meaning of the information.

 

We have also found that user interfaces normally fail to be extendable in such situations. The requirements on usability are so high today som users don't accept something bad generated thing coming from these key/value and enumeration constructions in the domain model.

 

/Tomas 

---

Från: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] För Stefan Moser
Skickat: den 27 september 2008 00:12
Till: domaindrivendesign@yahoogroups.com
Ämne: Re: [domaindrivendesign] Customizing a domain model

I worked on a project with similar requirements in the past.  One question you have to ask yourself is does any *logic* change with any of these customization properties. 

 

Here is an example.  Let's say that your application manages parties (the ones with food and drinks and fun) and a major part of your domain is tracking how much fun a person is having.  So you have a Person entity.  Now one of your customers wants to customize the application to add HairColor to the Person entity.  Are they also able to change the *logic* within the Person entity so that when HairColor == HairColor.Blonde that they can also say Fun++?  Sorry, I just couldn't resist. :-)

 

But seriously, it is rarely the case that these kinds of applications allow the customization to have any effect on business logic.  If this is the case, you're basically dealing with this part of the application being simple forms over data.  One way that this can be handled is to not change the core Person in anyay, but to decorate the Person outside of the domain boundaries.

 

Depending on the complexity of your customization requirements, this could become its own pseudo bounded context.  The one I worked on actually had a fair amount of logic in how the customization was set up.

 

The project started with the "let's just extend the database tables" approach, but this caused ssssooooo many problems that I would recommend not going down that route at all.

 

I know it's vague, but hope that helps a little.

 

Stefan

On Fri, Sep 26, 2008 at 2:20 PM, Jørn Wildt <jw@fjeldgruppen.dk> wrote:

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

It's funny how the more I obsess over this topic and search the web
for opinions, the more my own thoughts have already
been...er..thought.

Check out this:

http://www.c2.com/cgi/wiki?DoubleDispatchExample

Which is saying essentially the same thing as Sequence.dialOn
(Dialable) and Dialable.dial(Sequence), except no stack overflow
danger. You'd have Dialable.dial(Sequence) do the actual dialing.

--- In domaindrivendesign@yahoogroups.com, "Zach Dennis"
<zach.dennis@...> wrote:
>
> > What do you think keeping your options open by using both (aside
from
> > the clear potential infinite loop)?
>
> > DialableDevice.dial(Sequence) and Sequence.dialOn(DialableDevice)
>
> If you go this route, so much for SRP.
>
>
> --
> Zach Dennis
> http://www.continuousthinking.com
> http://www.mutuallyhuman.com
>