Modeling a loosely coupled domain model

Question

The question does not really apply to DDD, but would like to know if there is a way to model a loosely coupled domain model. What I mean? I am working on HR software editor and we plan to start a new application from scratch. We have audited all the projects that we have done for our 150 clients, and the fact is that we cannot say that there is one valid domain model in terms of DDD.

Why? Because each company deals with HR differently depending on how big the company is, etc. Etc.

Of course, we can identify the essential entities in the HR domain, such as: work, offer, co-author, skills, etc., but they are not related equally for client A and client B. So, from the point of view of the domain model, we cannot say that Entity A has a link to Entity B, which have a set of skills, because this will not be true for another client.

Even if for 80% of our customers we can design a model that addresses 90% of our needs, we will not sacrifice other customers, but on the other hand we would like to have a product with a specific design to solve various problems.

We looked at BPM solutions, but this does not fit our needs. On the other hand, I can’t imagine how you can cope with what we need. In fact, communications between objects should be executed at runtime from a kind of parameter, xml, etc. For every customer. We would not need to code another application because the domain model has changed slightly. It may be completely insane not to have a domain propper model, but something based on messaging could help us.

I would like to know about this. How did you deal with such situations.

Thanks,

Answer 1

The goal of a domain model is to encapsulate common behaviors and relationships . Although you can (and should) freely link your implementation, there are limitations on how you manage the configuration.

If you continue to push it toward a larger and larger configuration, at some point it will cease to be a domain model and will instead become a Framework . You can then use the Framework to define specific domain models.

Writing a framework program is really very difficult, so I don’t think it would be a feasible plan to launch a project with this explicit purpose.

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

With a lot of time, luck and skills, you can evolve this core into a domain infrastructure .. p>

Answer 2

"The problem with the magic product," we are all looking for one of them :). I have just successfully used SOA. We did a good job identifying the services, and later we changed the settings or business services a bit.

What I'm trying to say is that you can never solve all the differences in configuration, I have to make an effort to make good code thinking in easy adaptation, but IMHO, a "magic product" is impossible.