Modeling loosely coupled domain model

Question

Hello,

The question doesn't really concerne DDD but would like to know if there is any way to model a loosely coupled domain model. What I mean by that ? I work for a software HR editor and we're planning to start a new application from scratch. We did an audit of all projects we did for our 150 customers and the fact is that we can't say there is one valid domain model from the point of view of DDD.

Why ? Because each company deals with HR in different ways depending on how big the company is, etc. etc.

Of course we can identify commun entities in HR domain like: job, offer, collaborator, skills, etc, but they are not linked the same way for the client A and the client B. So from the point of view of Domain Model we can't say that Entity A has a reference to Entity B which have a collection of skills because it won't be true for another customer.

Even if for 80% of our customer we can design a model that adresses 90% of needs we won't sacrify the rest of the customers and on the other hand would like to have a product witouht doing specific development to address differents concerns.

We looked at BPM solutions but that doesn't fit well with our needs. On the other hand I can't imagine how you can handle what we need. In fact the links between entities should be "done" at runtime from a sort of parameter, xml, etc. for each client. We would like to not have to code another application because the domain model has slightly changed. This could be completely insane to not have a propper Domain Model but something based on messaging could help us.

Would like your thoughs about that. How did you deal with such a situations.

Thanks,

Answer 1

"The magic product issue", all of us are looking for one of those :). I have just done one with success using SOA. We made a good work identifing the services and later we just changed a little the orchestations or the business services.

What I am trying to say is that you will never be able to address all the differences by configuration, I should put the effort in doing a good code thinking in an easy adaptability, but, IMHO, the "magic product" is impossible.

Answer 2

The purpose of a Domain Model is to encapsulate common behaviors and relationships. While you can (and should) loosely couple your implementation, there are limits to how configuration-driven you can make it.

If you keep pushing it towards more and more configurability, at a certain point it will stop being a Domain Model and instead become a Framework. You can then use the Framework to define specific Domain Models.

Writing a Framework is really, really hard, so I don't think it would be a feasible plan to start a project with that explicit goal.

If you can, start with a common code base and every time you get a customer-specific request, refactor the kernel so that you can implement the customer feature as a plugin.

With lots of time, luck and skill, you may be able to evolve that kernel into a Domain-Specific Framework.