Applying Domain Driven Design to an analysis driven domain

Question

I am currently working on a domain that is fundamentally driven by analytics. I'll use a fictitious example to illustrate my question.

Suppose the application is a service based on House Prices. The goal is to use predictions generated by a data analysis pipeline to help real estate agents make buying and selling decisions. The data analysis pipeline analyzes pricing trends in the market, takes into account seasonality, and specific events to make its predictions. The underlying factors (events, seasonality, etc.) that were used to make the prediction are also surfaced to the users (so the process is not a black-box). The reason for surfacing these factors is to give the real estate agents a justification for why they can ask for a particular price (for example). These results then need to be surfaced to the users (real estate agents) on a web portal.

This is where I am unsure if a Domain Driven Design makes sense or not. For instance, I can see there may be a certain ubiquitous language (I know nothing about real estate) that could be beneficial, for instance. But my concern is that this domain does not really have any invariants that need to be enforced: these are essentially defined by the algorithm behind the analysis and not strictly any business rules. So, the domain models essentially get populated with the results from the analysis. Secondly, I may define a rigid structure like the factors can only be PricingTrend and an abstract Event class that is then sub-classed to define different kinds of events. But, then I can see that the analysis model may evolve rapidly and the domain itself may not be stable enough to be reliably vended out to clients. I'd also need to take care of rampant polymorphism and to define a stable enough core structure for Events. Additionally, if different kinds of Events are identified down the line, the domain model needs to be updated to keep up with the analysis itself. Finally, what if the analysis we were doing turns out to be suboptimal and we fundamentally alter our approach, in that case too, the domain should ideally reflect the change, or else, needs to be abstract enough to absorb such a shift.

So, I am not sure if I get any benefits by using DDD in this context. If not, what else can be used in such a data-driven domain that can still serve as a good representation model that is stable enough to build a service on?

Edit: I can foresee autonomous third-party systems integrating with the system described above to make the buying and selling decisions as well. To maintain a stable integration, I see a need for a stable model abstracted away from the underlying analysis producing the results. For instance, if it is clear that a few generic concepts (like Events above) are stable in the long term, then the problem essentially shifts to properly modelling such a generic class, which the clients can reliably consume. Given this future requirement as well, is DDD a good modelling solution for this case? Also, since the Event types can grow quite drastically (keeping with the analysis pipeline), is DDD ideal for modelling this model-dependent evolving domain?

Answer 1

There's a couple of points here.

First, I'm unsure what you mean by "Domain-Driven Design". If you mean an anemic-object, data-structure based "model", then you probably have a different interpretation of DDD than me. You say "domain models get populated with results", and that is not how it should work. An object represents something, it's not a container for data.

Second, the model does not have to be flexible at all, and does not need to "absorb a shift". Exactly the opposite is true, it needs to be as tight as possible describing your domain, so any change will have a visible consequence in code. Think of it this way, the model essentially describes your state of knowledge at the time you write it. If that knowledge changes the code should at that point describe an invalid state, so it needs to change.

You can't avoid work by making the model flexible, essentially hiding domain knowledge. You will make the model imprecise that way and error prone. Embrace change, and use proper encapsulation to limit the effects.

So DDD with pure data structures won't help you, but DDD as in thinking about and modeling the knowledge / behavior of your domain will.

Answer 2

If I am understanding your description, it sounds like your system is all about:

1. Collecting data
2. Applying rules to find patterns (correlations, predicting missing variables etc.)
3. Presenting the results to users (the predictions plus the data and the rules that led to them)

I have seen attempts to build systems like this using DDD only to find that the domain layer is very light on business rules and all the real value is in the queries or the analytics.

It sounds closer to a data science project and may not be the best fit for DDD. DDD would be good if you need to model a housing system and encapsulate complex rules about houses, pricing etc. which would support a variety of use cases. In your case, the business rules about the entities are not really where the value is. The value is in the patterns in the data you are collecting.

I would be looking at pushing the data into a data warehouse or similar and then applying algorithms using R or other M/L tools. You could store the results which could then be presented to users.