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?

2 Answers 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.

  • This is an apt description of the system's goal. The reason I am trying to model the results in a standardized way is to ensure that if any clients (systems) are consuming the results, say to automate the sales decisions, they can do so in a reliable and stable manner. This requirement was not very explicit in the original post, but, I think it will come up over time (I've edited the post accordingly). Curious if this requirement (vending the results to clients) changes your recommendation.
    – Cosmica
    Jun 18, 2020 at 13:56
  • I see.. you are wanting to model the results only. It's hard to be sure without more details but I would consider DDD if the model is complex enough with a significant amount of behaviour (business rules) and you may want to build multiple systems on top of it over time. It's not a hard and fast rule but DDD feels overkill in this case. DDD is also not required to provide stability for clients; you can do this by providing a stable API that isolates the underlying data changes from how they are presented to users. Jun 18, 2020 at 14:31

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.

  • "An object represents something, it's not a container for data." is exactly what I am saying as well (apologies if it is not coming across as such). In this case, however, since (only) the analysis produces the domain data, it is defining the business rules and my models are reduced to data containers. DDD could be used to capture the "represents something" component that makes sense to users (domain experts) but I cannot see it incorporating any behavior in my case. So, what I am looking for is perhaps a translation layer, and, I am wondering what design paradigm is the best fit.
    – Cosmica
    Jun 18, 2020 at 8:16
  • @Cosmica The analysis could be the behavior. I mean depending on the exact case the data would probably not mean much without it's analysis. Or the analysis can not be changed significantly if its data doesn't change. So a thing like Price might have methods to analyze it, like Price.movingAverage(): MovingAveragePrice, and similar. Jun 18, 2020 at 9:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.