How to handle Domain Driven Design when domain is dynamic / changes

Question

In order to make it clear what I mean, let us build a hypothetical scenario where this might be needed.

Let us say I am building some software for a company that manages whiskey breweries in Scotland. Each brewery company can have a copy of this software to manage all the business logistics.

Assume that I have a Kettle object, and on it we'll have some properties, e.g. .Colour and .Material.

But what if the Glenfiddich brewery wants another property on the domain? e.g. .Size and some other brewery doesn't care about all the above and is only interested in .Content and .DateFermentationStarted?

In OOP is there a way I can make my Kettle object dynamic (have different properties and methods) depending on some parameter named Customer?

If I'm not mistaken, this is very different from Polymorphsim.

Answer 1

You can't apply much DDD in this scenario, because the Domain concepts definition change from one client to another. I mean we all have a Kettle but there can be of any property the client wants. How can you apply behaviour? More precisely on what?

At most your "domain" objects will be data structures. It does matter who gets a saying in defining objects and what the customizing options are. If for example, a client can choose from predefined properties then you have some room to maneuver.

But if they can add any property with any name, you're losing semantics and just end up with data structures made up of magic strings. And you can't enforce business rules, unless you also have a business rule editor that clients can use to define rules. And that would be quite complicated for both developer and client.

So, IMO, DDD is not really suitable for this unless you're building separate apps for each customer, but proper OOP still is. You'll be working with data structures though and probably an ORM will help here.

Answer 2

If those properties are dynamic, you have several options.

1. to have a base class with common properties and then to derive new classes with defined new properties. This solution has a problem however - you have to create different build for each customer that needs special properties. The plus is that the system is fully documented in sense of explicit properties on code level.

2. To model Property as a separate autonomus class and to be able to create instances of properties and assign them to domain objects in run-time. Properties can be defined in DB (with their names, maybe data types) and assigned to certain domain classes that need then. This way there is no need to make new builds for each different configuration, only a DB update is necessary.

This simple class diagrams shows the idea:

Additional properties are defined in the DB and than in run-time read and assigned to domain object.