Domain logic and SQL

[Kainar01]

HI! Thank you for this great repository! This repository helped a lot to understand a lot of patterns from P of EAA by Martin Fowler in practice. But I stumbled upon a problem.

I was thinking about a case when I need validations that use SQL. In-memory validation would be too inefficient since I might need to load thousands of data in to the memory. Following DDD, we must have pure domain model, meaning we can't have dependency on other layers. So, I have 2 options in my mind:

1. Create a command for handling validation. And this can be used everywhere to validate. But I would no longer be able to enforce validation.
2. Validate using domain events. This seems like a good way of doing this, since it would enforce validation, but is it a good practice to have validation in domain event handlers?

Or is there a better way to do this?

Also, Martin Fowler in his book talks about this issue. But he says we should use stored procedures or views in database. But does not talk about where we should call these methods.

Edit:
I also have another option, which is passing validator class in domain model method upon calling it. But anyone who uses this method would have to explicitly pass validator upon calling it. Is this a better practice?

[Sairyss]

Hey.

What do you mean by "validations that use SQL"? Also, I don't understand why do you want to use commands/events for validation, seems like you are overthinking it a little.

You need to validate data that comes from a database, am I understanding it correctly? If so, I see two options:

1. If your database is accessed only by your app and nothing else, and all input that you save is validated (in your controllers for example), I don't see much sense validating it again when you query, since it's already validated before it was saved (you could do it just for the extra safety if you prefer though)
2. If your database is accessed by something else (some other app, or directly by team members) and you worry that queried data may be corrupted (for example when overwritten by somebody who has access to the db), you may validate it in the same place you query it (for example using schemas like in the user repository).

Validation must be synchronous and you have to wait until it finishes before doing something else with that data.
IMO forget about efficiency, you can't tell if it's efficient or not until it's running and you benchmarked it. Zod for example can validate 100.000 rows in ~25ms. Your query time including network trips to the database and back will take more time than in-memory validation.

[Kainar01]

But I still have no idea where I would fit those SQL queries. Should I put them in validation class and my entity would use that class, or do I do those kind of stuff in command handlers?

By the way, I have check this ddd repo, where he validates if comment like is unique before inserting it. Basically he passes like count for on the comment for given user to entity, where he validates that it has to be 0 before inserting.

[Sairyss]

Depends on the use case. Usually queries just go into the repository/query handler class, and called by a service/command handler. Following your example with uniqueness validation you can just execute repository insert method from the service/command handler and catch the "unique violation error" (or any error that you are expecting)

class UserService {
  constructor(private readonly userRepo: UserRepository;) {}

  createUser(dto) {
    const userEntity = new UserEntity(dto);
    try {
      await this.userRepo.insert(userEntity)
    } catch (err) {
     if (err.code === 'unique_violation') {
       return new UserAlreadyExistsError();
     }
     if (err.code === 'some_other_validation_error') {
       return new SomeOtherError();
    }
     // else ...
    }

[Kainar01]

Got it, thank you very much!

[emedina]

@Kainar01 you may also take a look at this video where Milan explains nicely a similar problem to yours: validation that involves multiple aggregates, such as the uniqueness of an email, from the DDD CAP theorem point of view -> https://www.youtube.com/watch?v=eC7GMGIR4Gw&t=101s

[Kainar01]

@emedina hey, thanks so much! Although I've already figured out these approaches myself (which took me much longer than this video would), it was still really informative. I think I will watch his other DDD videos as well.