Domain driven design model version

Question

sorry for the long question, but I love DDD but there is a problem I can't seem to resolve.

We have a problem when adding business rules to the aggregate root.

Our architecture is mostly like this when we make a query from the front-end :

For a simple example, we have a Book we want

1. to persist
2. fetch it.

The book has

Name which has to be 10 characters and an Author which needs 15 characters.

Here the pseudo code in TypeScript:

class BookAggregateRoot {
   private _name: string;
   private _author: string;
   private constructor(name: string, author: string) {
       this._name= name;
       this._author= author;
   }

   static create(name: string, author: string): BookAggregateRoot {
       if(name.length < 10) {
           throw error; // not really throwing, its just to show we have an error
       }
       if(author.length < 15) {
           throw error; // not really throwing, its just to show we have an error
       }
       // all data is valid, create the Book
       return BookAggregateRoot(name, author);
   }
}

1st Scenario : save the book

Client -> DTO -> controllers -> useCases(1. calls create from Book class) -> calls repositories(persist the data) -> database -> data is returned, repositories(2. calls create from Book class) -> useCases -> mapperToDTO-> controller -> client.

2nd Scenario : fetch the saved book

Fetching data is in the same way but only, dont need to persist, only fetch the data : Client -> DTO -> controllers -> useCases(builds the query) -> calls repositories(query) -> database -> repositories(3. calls create from Book class) -> useCases -> mapperToDTO-> controller -> client.

As long as the business rules don't change, it's fine as the data stored and the data fetched has the same business rules.

The problem lies in the creating of the AggregateRoot. Let's say now my Book needs a publishedDate, all data that previously doesn't satisfy the data fetched from the database and will fail at step 3.

The class now becomes :

class BookAggregateRoot {
   private _name: string;
   private _author: string;
   private _publishedDate: Date;
   private constructor(name: string, author: string, publishedDate: Date) {
       this._name= name;
       this._author= author;
       this._publishedDate = publishedDate;
   }

   static create(name: string, author: string, publishedDate: Date): BookAggregateRoot {
       if(name.length < 10) {
           throw error; // not really throwing, its just to show we have an error
       }
       if(author.length < 15) {
           throw error; // not really throwing, its just to show we have an error
       }
       if(publishedDate.invalid) {
           throw error; // not really throwing, its just to show we have an error
       }
       // all data is valid, create the Book
       return BookAggregateRoot(name, author, publishedDate);
   }
}

the data will always fail at step 3. above as the create requires a date.

We could create a migration to fix all the data... but is that the right approach?

thanx in advance and let me know if there is anything to better the design. :)

Answer 1

If the business requires that you store an additional field/column of data, then there are essentially three possibilities:

1. You modify the code to require the new field but don't touch the old data. This effectively renders the existing data inaccessible which is not likely to be accepted by the business.
2. You write the reading code such that it can handle the missing field. This also means you have to mark the column in the database itself as optional (nullable) and you will have to assume that the field will become empty also for data entered after the change.
3. You migrate the existing data to include (a sensible default for) the new field. This would be a one-time operation that does not complicate the normal flow of the application.

Answer 2

I don't know the structure of your domain, or what other domain objects you have, but have you thought deeply about how you are structuring your code.

At some level it makes sense that you or I could create a book. Creating a book isn't the same as publishing one. For example, I could write a memoir and never get it published.

With that in mind, would it be possible to restructure the code so that the published date is optional?

public void PublishBook(DateTime datePublished){
   _publishedDate = publishedDate;
}

Your constructor the doesn't need to check if the published date is set. Also, I've found that creating a object that represents the data record that I can pass to the constructor of my aggregate, transforming it as necessary to fit the aggregate is a nice pattern that makes it easier to update aggregates when refactoring as you don't always need to change the constructor.

Check the premise of the book aggregate. At a broader level maybe there should be a publisher that accepts a book record and does the publishing? Like I said depends on the rest of your domain. Regardless, passing an object instead of individual values to your aggregate root will make life easier in the future.