I'm new to DDD, so please bear with me.

I am trying to design a domain model around an extremely large and complex existing system, where most of the current "domain" logic is either in the UI or in the persistence tier. The need is to begin moving some of this logic into a domain model that can be used for our server (such as APIs) or client application. I can't move all that logic to the domain model yet, but we can certainly start.

There are several things that we're planning on rolling into the domain model that would be shared between our client application and the server:

  • Logical structure of our domain.
    • Currently all tiers talk to the system using something that matches the database structure, and that's just not how the concepts in our domain are structured.
  • Typical domain events. X happened, so do Y.
    • Y could also make other values in the domain model required or not, so it would impact validation.
  • Validating themselves based on their state (field B required because A has a certain value).

In addition to any server handling of the domain, we have the need for our user interface (C#/WPF application) to show users the current state of the domain as they manipulate it. We're planning on running parts of the domain model in the client application and exposing it to the UI with appropriate view models. We'll have fields that get wired up (not directly) to the domain model's entities so that as users enter in values the domain model can respond to those inputs and perform the appropriate domain events.

Any one entity will be responsible for several things

  • Knowing what properties are required
    • Updates to the set of required fields would be handled by domain events
  • Knowing what value is appropriate for individual properties
    • Strings must be no longer than X characters, or a value cannot be negative

Due to the nature of data entry, it's possible for an entity to be invalid at any particular point before a save validation is triggered.

This means that the entities need a way to track what field is required at any one moment and whether those fields have satisfactory values. This would be in addition to any cross-entity validations that must be enforced; such as having each entity in a collection requiring distinct values for a particular property.

So, to my question:

What is a good pattern for the domain model to expose metadata about its properties to facilitate the needs of our application?

Examples of this metadata:

  • Is it currently required, invalid, or not available at any one moment
  • What values are even allowed
  • Perhaps extending this concept to allow the domain model to state what is wrong with a particular field

This metadata would end up being reflected in the UI (required fields would show as such) and it would be used during validation of the domain model.

  • Unfortunately the scope of DDD does not extend to your UI. That is, UI validation is under the purview of the UI itself, and should remain independent of your domain. Understandably duplicating logic can be annoying, but there really aren't many domain-centric patterns for dealing with this (without accidentally falling into an inner platform effect). Mar 13, 2019 at 17:02
  • @king-side-slide I was more interested in patterns on how domain object properties should expose their current state, than on how to express that in the user interface. Hopefully that makes sense.
    – Nathan
    Mar 14, 2019 at 15:02
  • Put simply, they don't. Remember DDD is about managing complexity (i.e interleaving/dependencies). There is nothing inherently complex about what something is (e.g. current state). The complexity is about how something behaves. If your state were to never change, there would be no need for a domain model. The usual approach here is to adopt a CQRS pattern and let the UI query for whatever state may be of interest in whichever way(s) it sees fit. The simplest way to achieve this is to simply issue SELECT queries as appropriate. Mar 15, 2019 at 16:29


Your Answer

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