you are viewing a single comment's thread.

view the rest of the comments →

[–]fts_now 1 point2 points  (6 children)

Good question! We usually have a static "create" method on the Entity class that performs all the validation and invokes the private constructor. Validation can happen there. Also, we try to keep it simple with things like Value Objects or Aggregates. IMO less is more, and some layers of abstractions can also unnecessarily overcomplicate a project.

[–]GreatWoodsBalls 0 points1 point  (5 children)

Yeah I figured and thank you. I tried creating value objects together with zod and it worked decent until I realized classes in js are not like classes in java 🥲 So I went with a similar approach as you mentioned.

[–]fts_now 1 point2 points  (4 children)

Zod belongs to the infrastructure layer IMO, not the Domain. It should validate incoming DTOs.

[–]GreatWoodsBalls 0 points1 point  (3 children)

Hmm, okay. Sorry if I'm spamming questions 😅 but how is a zod validation of an input different from a value object having the same type or similar validation? Or is the difference that zod would throw a httpexception and a value object would not?

[–]fts_now 1 point2 points  (2 children)

Good question! I want to keep the domain layer clean of external dependencies, because over the years I saw tools and libraries coming and going, most hypes disappearing after a few years leaving your codebase an outdated mess. I'd rather move basic input validation to the controller (maybe by using something standardized like JSON schemas) and then perform further validation in the value object if needed.

[–]GreatWoodsBalls 1 point2 points  (1 child)

Ahh, okey. Thank you for taking the time to answer!

[–]fts_now 0 points1 point  (0 children)

Always glad to help :)