0

I am using Domain-Driven Design with Railway-oriented programming as an exception handling method.

Every value object will not throw an Error, but return a Result type to indicate if it failed or succeed.

Here is my process:

  1. Command Triggered
  2. Loading data from the database to the domain
  3. Process changes
  4. Saving domain data to the database

I am stuck at step 2, loading the data from the database to the domain. The data which is loaded from the database will be passed to the domain as value objects, which currently have validation.

I figure out that validating the data that I get from the database is kinda dumb because if we change the rules in the value object, the old data might be invalid and could be never updated. In other words, I will lose data after changing some code.

I would like to know that should I validate the data that I get from the database or create a reconstitute method/function, which just uses the data to create the value objects without validating it?

6
  • @DocBrown Please see my edits. The "dumb" part is about the future data lost which the user cannot do anything to change that. I also define what my reconstitute method is. Thank you. Dec 22 '21 at 4:47
  • You don't validate data, rather, behavior. Through this practice it becomes unimportant whether or not the data within an object is "valid", because it is when you intend to actually do something with your object that you include validation. Does that make sense? If you have rules about what a User can purchase, we want those rules to be enforced on User::purchase not User::construct. Dec 22 '21 at 14:43
  • @king-side-slide I got your idea, but there is some validation like name length cannot be less than 3. This validation is put in the constructor or static factory method. If this is validation rule is changed, says name length cannot be less than 4, then we might lose some data. Dec 23 '21 at 6:25
  • > there is some validation like name length cannot be less than 3. I bet you can think of a way to co-locate the validation of the name length with where name changes. Dec 23 '21 at 16:02
  • @king-side-slide If I put it where the name changes, I should put it where I create the object which has name too. And I don't think duplicate logic is a good idea. Dec 24 '21 at 1:15
3

When and where to validate data depends on the kind of application you are building, the use cases (and their quality requirement on the input data), and on the constraints implemented in your database. Rules which are enforced by constraints on the DB usually don't have to be validated on the application side as long as there is no process implemented in your application which can change the data before it will be used. However, there will usually exist certain rules not implemented as db constraints, because they may change dynamically, or may be not be enforced at all times or not for all records of a data set.

Since you were talking about "changing the rules", let me focus on application-side validation, and not database constraints. In most systems which utilize a database, one will have a distinction between

  1. Loading and saving some data from the db.

  2. Using or processing the data in certain use cases or processing steps, either interactively or automatically or both.

Application-side validation (or domain-object validation) should not be intermixed with #1, and not entangled with it, otherwise you don't have a chance implement processes like

  • editing of data interactively (with intermediate, invalid states)
  • correction of the data (for example, after change of a business rule which makes certain objects invalid)
  • quality assurance (where you want to display the data in its invalid state)

Hence, be careful what kind of validation you enforce at construction time in your domain objects, and which validation rules you provide as separate methods, which might be called at a later point in time. Making the construction-time validation too strict would forbid to implement certain use cases.

However, certain use cases may require more strictly validated input data, or require to strictly validate their output data before it is processed further.

That is where you have to look at:

  • find out which use case needs to have which business rules enforced, and when

  • implement validation rules for those, and call them at the appropriate places (which is not necessarily after the data was loaded from a DB, but maybe at a later point in time)

Of course, when your system does not support any use cases which allow correction or quality assurance of the domain objects's content, then you can do the validation also at construction time.

In short: the decision of which valiation rules to apply immediately when an object is loaded from a database depends heavily on the use cases of your system, and it is not an "all-or-nothing" decision.

8
  • You and I might have some misunderstandings. I have edited my question again to make it clearer. So in DDD, if you want to change something, you have to do it with the domain, right? When I execute a command, I have to get the data from the database and create a domain object using that data. But the domain contains value objects, which have validation to make sure the domain is valid. But these validations could have changed as I said. As you said, I have to distinct between loading/saving data and processing the data. But what would you do when every data must go from/to the domain object? Dec 22 '21 at 7:34
  • @NgọcNguyễn: it sounds you are assuming all validation must be enforced at construction time of a domain object, did I get you right?
    – Doc Brown
    Dec 22 '21 at 8:22
  • You got me right :) Dec 22 '21 at 8:29
  • @NgọcNguyễn: well, that's you misconception here, see my edit.
    – Doc Brown
    Dec 22 '21 at 8:39
  • 2
    @NgọcNguyễn: these implementation details don't matter. What's important is the specific validation logic you have put into the construction process (regardless if this is implemented through a ctor, or by a factory, or differently), and which specific validation logic you left out there / implemented elsewhere, and if those validations and the point in time where they happen match the use cases in your system.
    – Doc Brown
    Dec 22 '21 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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