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.