Re: Real World DDD.

Hey again folks,

Well, Jaune, OK.

In my experience I have actually never heard the term domain expert 
being used to refer to business people.  I have, however, heard the 
term Subject Matter Expert (SME).

It may very well be that domain experts don't tell us everything 
because they may reckon it is obvious or even think that we may not 
understand (at that point).

I certainly do not try to explain my field to domain experts --- they 
do not care and probably would end up with one eye staring to the 
left and the other hopping up and down.

Domain experts, users, managers, CEOs, and catering staff do not care 
what our development artifacts look like (except maybe 
documetation).  They only care for the information and behaviour 
(surprise, surprise) of the system.

So I am of the opinion that just as there is an impendance mismatch 
beween an OO class model and a relational model there is also the 
same mismatch w.r.t. how domain experts and developers see and 
materialize the world.

Enter the ubiquitous language.  It is the common ground.  Developers 
still implement the requirements using whatever technology is 
required and business folk carry on with their lives.

User Defined Fields and the Core Domain

I recently joined a company and started working on the next generation
of its main product. The product is a "staffing" system designed for
HR executives, hiring managers and recruiters. Certainly, the domain
is about hiring process---Candidates, Resumes, Jobs, Workflows,
Interviews, searches/matches, and so on. 
One of the shiniest and most important features the system offers is
the support of "User-Defined-Field"(UDF).  In short, user can define
and manage theoretically "unlimited" number of skin-able, editable,
reportable, searchable fields,   in different data types including
single and multi selects, and for almost any major business entities.
 For example, adding an "age group" field to Person. As you could
imagine, the feature doesn't come free. It complicated the whole
system from the bottom data layer to the top presentation layer; it
had also caused some performance problems.
The older design treats UDF as part of the core domain.  That said,
any UDF-enabled business entity is derived from a common base class
which has UDF mechanism built in. For example:

// UDFBase contains methods and members to describe UDF and to store UDF
class UDFBase
{
	Dictionary<FieldDescriptor, Field> fieldDictionary;
public Field GetUserDefinedField(FieldDescriptor fieldDescriptor);
//...
}
class Person: UFBase
{
       //..etc
}

SV: Re: Real World DDD.

> In my opinion, the Domain Model and the Core Domain (including the
most important processes) should be owned by the project. By the
prople knowing software and other formal things.

  mmm, I agree that computer people are the one who think OO, and are
the one who need everybody to think OO/Domain, so they will be leader
in DDD. I think that if coders feel they "own" the domain, they are
making a big mistake. Everybody must be responsible for the model or
it is not ubiquitous (let's say tech guys are responsible for
maintaining the UML diagrams and for teaching business experts to read
the simple ones).

  Domain experts must learn to use precise words and express the
business rules, people from marketing must learn that there are lot of
things (code, relations, data format, rules, algorithms) behind the
words they use, and coders must stop being lazy and just code to
fulfill the requirements, but must code something which behave and is
designed as other people think it is.

  When you find yourself in one of those two situation :
-Marketing people of business experts ask for something that they
think is just a small modification but you tell them you need 2 months
to code it
-Your third level supporting team can't understand question from the users
It is certainly because the domain model "belongs to" the coders (read
: is not ubiquitous). If there is a mismatch between how complicated
business expert and coders think is a dev, it can be because the dev
implies some deep refactoring and technical things, but often it is either
-because business people don't understand that they are speaking about

Re: User Defined Fields and the Core Domain

Hi Sam,

I hope you are aware that your user-defined fields force you to think a
lot more about your physical data model than what is normally considered
healthy in this group.

You would do well hiding all that from your domain model and keep your
domain model pure and simple - the composition of domain entities from
UDF and regular data should go in a separate subsystem indeed. Depending
on the programming language of choice, you may be able to compose domain
objects at runtime and use reflection where needed. Scripting languages
may be more suited for this than Java or C#.

You haven't indicated the extent of flexibility your UDFs need to
provide, for example are they simple properties or could they be
associations and collections as well? And if yes, then how are you
realizing referential integrity and other constraints? Are you planning
to provide any validation on UDFs? And will this be coded in your
application or in your database?

Good luck, and make sure you let us know what your final design wil lbe,
or even better tell us in a year from now what your field experience is!

Bert
--- In domaindrivendesign <at> yahoogroups.com, "Sam Peng" <sam.s.peng@...>
wrote:
>
> I recently joined a company and started working on the next generation
> of its main product. The product is a "staffing" system designed for

Re: User Defined Fields and the Core Domain

Hello Sam,

Now this is just typical!  Users want everything and it seems a mess.

Now the question is: why do they want it?

I would venture a guess.  They want the searches (as you mentioned).  
But maybe its more.  It could have something to do with reporting.  
They may want classification schemes within which the want to report.

My suggestion would also be to simply remove it from your core domain.  
Then create a separate domain for searching / reporting... in fact it 
is a metadata domain used to create arbitrary values linked that are 
simply "attached" to real domain entities.  Of course, the users 
wouldn't necessarily see this distinction on your front-end.

To be thinking about the data:  you could then have a different set of 
tables to manages this metadata about your entities and use *that* in 
the front-end to access the identities of the real entities attached to 
the metadata.

Hope this makes sense???

Regards,
Eben

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

Re: User Defined Fields and the Core Domain

Hi Bert,

Thanks for your quick reply.

Yes I am aware of the challenge in the physical data model, more
specifically, in how to efficiency store/load/search UDFs and relates
them to their owning entities, especially when number of UDFs and
number of entities are getting huge.

Yes, again, the UDFs can have complicated associations--for example, a
Person can be associated with a Job Application, and a Job Application
is associated with a Job and further to an Employer. Person, Job and
Employer are all "UDF-able". The user of the system could issue a
search like "Find all the persons [aged from 25 to 35] who [owns three
dogs] and had applied a job which posted by companies whose [User
Rating] is bigger than 3", 

There will be challenges---the complexity of data model and entity
relationships convinced me more that I should separate the UDF from
the domain model.

By the way, we use C# on .Net.  Likely we will heavily use the .Net
reflection for managing some static aspects of UDFs. 

Thanks,

Sam

--- In domaindrivendesign <at> yahoogroups.com, "berthooyman"
<bert.hooyman@...> wrote:

Re: Re: User Defined Fields and the Core Domain

Hi Sam,

I'd be happy to discuss this more with you in person but I know the
problem space reasonably well through Stefan.

I might consider a radical departure from the current architecture.
This "domain" isn't really a domain that is well suited towards a
relational database. Instead I would probably work with a document
centric system where the back end persistence is a document model
(such as XML) where your searches then hit that XML.

The domain as such can still be "pure" and the metadata can be easily
added. There are some great tools out there for managing/searching
massive numbers of documents in scenarios like this.

Cheers,

Greg

On Tue, Jul 1, 2008 at 12:45 AM, Sam Peng <sam.s.peng <at> gmail.com> wrote:
> Hi Bert,
>
> Thanks for your quick reply.
>
> Yes I am aware of the challenge in the physical data model, more
> specifically, in how to efficiency store/load/search UDFs and relates
> them to their owning entities, especially when number of UDFs and
> number of entities are getting huge.
>
> Yes, again, the UDFs can have complicated associations--for example, a

Task / Domain Service / Rich Domain Model

Hello,

OK... so a buddy of mine reckons that task / domain service processes 
should be on the actual entity else the entity is simply a container.

Putting the processes on the entity would, of course, require the 
entity to access repositories and have access to other tasks and stuff.

It would also mean that I can ask for a list of the entity type and 
then also have it responsible for its lifecycle... seems somewhat wrong.

Any opinions on this?

Regards,
Eben

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

Re: Task / Domain Service / Rich Domain Model

Re: Task / Domain Service / Rich Domain Model

*lol*

That is exactly what I said...

Cheers,
Eben

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