---
title: 'Laravel Validated DTO: Single Source of Truth for Data'
source: 'https://youtube.com/watch?v=IxnQUlDxPX0'
video_id: 'IxnQUlDxPX0'
date: 2026-08-14
duration_sec: 680
---

# Laravel Validated DTO: Single Source of Truth for Data

> Source: [Laravel Validated DTO: Single Source of Truth for Data](https://youtube.com/watch?v=IxnQUlDxPX0)

## Summary

This video demonstrates the Laravel Validated DTO package by Wendell Adriel, which combines form request validation with Data Transfer Objects (DTOs) to create a single source of truth for data transformations. The presenter shows a before-and-after comparison of a controller using traditional form requests versus the package, highlighting potential bugs that the package prevents.

### Key Points

- **Introduction to Laravel Validated DTO** [00:00] — The video introduces the Laravel Validated DTO package by Wendell Adriel, created three years ago, with 700 stars. It combines Laravel validation (form requests) with DTOs into a single class.
- **Demo Setup** [00:40] — A demo was built using Cloud Code, featuring a form to create an event with venue and tickets. The codebase has two options: regular form requests or validated DTO.
- **Problem with Traditional Form Requests** [01:08] — After validation, the validated array requires additional transformations: isPublic needs to be boolean, format needs an enum, and startsAt needs to be a Carbon immutable object. These transformations are repeated in multiple places, lacking a single source of truth.
- **Controller with Validated DTO** [02:06] — Using the package, the controller accepts a DTO object as a parameter, replacing the form request. The DTO handles casting and transformations automatically.
- **Payload Comparison** [02:37] — The payload from a form request contains strings (e.g., isPublic as '1', startsAt as a string). With validated DTO, isPublic becomes a boolean true, and the date format is a Carbon object.
- **Sponsor Segment: Flare** [03:27] — The video is sponsored by Spatie's Flare for error monitoring. Flare now supports AI error fixing via MCP and a CLI tool, allowing AI agents to analyze and fix bugs.
- **Five Potential Bugs Without DTO** [05:34] — The presenter shows five bugs that can occur without the package: 1) Carbon operations on strings, 2) enum casting forgotten in services, 3) boolean checks on strings, 4) DTO within DTO type errors, 5) field name mismatches (e.g., promo_code vs promotion_code).
- **DTO Class Structure** [08:14] — The CreateEventDTO extends ValidatedDTO, defining properties with types (enum, CarbonImmutable, boolean, other DTOs), rules (like form requests), defaults, casts, validation messages, attributes, and a transform method for field name differences.
- **Summary and Use Cases** [09:43] — Validated DTO is great for a single source of truth when operations after form request run elsewhere (queue, job, console command, service class). It casts everything to appropriate classes.
- **DTO Concept and PHP Evolution** [10:11] — The DTO concept is old, but PHP historically lacked strict type enforcement. Laravel now enforces return types, and packages like this add extra strictness for data shape consistency.

### Conclusion

Laravel Validated DTO provides a robust way to ensure data is correctly typed and transformed after validation, preventing common bugs and centralizing logic. It's particularly useful for complex data structures like arrays of arrays or parent-child relationships.

## Transcript

Hello guys, in this video I want to show you one Laravel package, Laravel Validated DTO by Wendell Adriel, who now works at Laravel, but he had created that package before he was cool and worked at Laravel, so three years ago.
It's not a new package, but very popular with 700 stars, with this idea. So we have validation of Laravel, like form requests, and we have DTOs if some developer wants to use that.
Why don't we combine them together in one class? So why don't we have a class, let's use a DTO with properties, with validation rules inside, and stuff like that. Let me show you that in action, and before and after.
So I asked Cloud Code to build me a demo, and we have a form to create an event with venue and with tickets, and we have two options in the same codebase, with regular form requests, or with validated DTO.
In the code, it briefly looks like this. So, legacy event controller with form request looks like this. And let me show you the problem that the package solves. So, typical thing, we have form request, and we have request validated,
which we'll then need to process with saving the data to the database, right? So, we have database transaction, for example, and then here, validated array needs additional transformations.
Right, for example, isPublic needs to be boolean, then format of the event has enum attached with these values, then we have formal code, is it filled or not, then we have array of venue, additional options,
and for all of those things we have additional transformations, transforming that to sum or for example starts at needs to be common immutable object. So, basically, we have the validation, which is passing, but then for further transformation,
if that transformation is needed in multiple places, for example, then we don't have one sub-sub, so to speak, one source of truth for all that big object of event with sub-object.
If we use a package, liable to validate a DTO, our controller may look like this. So, we have DTO object as parameter to store, which replaces form request with something like this.
It looks pretty complex, but let me explain the parts, and let me show you the actual consequence, what happens if we don't validate with extra DTO. So, if we fill in that form, which is already pre-filled with form request, with central form request,
and this is the payload that is passed through. Let me zoom that in a bit. So the payload looks like this. We have as public as one We have starts without typical carbon format So basically everywhere here we have strings But if we try the validated DTO controller
we send through DTO, and the result of that payload looks like this. See, the date format is different than is public. It's actually true, BLEAN, not one string,
and more changes inside, but this is not the actual difference. The actual difference is in the bugs that may appear if you don't use that package. So let me show you that. But before we do that, we have a sponsor for this video that allows me to create more and deeper videos about Laravel.
So this video is sponsored by Spotty, a well-known company in Laravel community and their product Flare for monitoring errors. But in 2026, it's not the same as it used to be like just monitor the errors and see the logs.
it's ready for the AI error. Let me show you. So here I am in my own Flare dashboard. I'm using that on my project AI coding day.com and this is one of the errors that appeared. So I can read
the details, I can read the request, all the typical stuff of error monitoring applications. But what is really useful is not seen. I would actually, if I were a spy, I would make it more
visible is copy for AI button and there are actually even two features in one. You can use Flare MCP or the recently released CLI tool. So in my case I configured MCP and this is configurable in cloud code. For example, what's this?
You create API token here on the dashboard then you authenticate with the token and from there you launch cloud code and after getting this error you do copy for AI, copy prompt and paste here. And let's see if Cloud Code is able to fix this.
I have a suspicion that this is just a bot attack on live wire endpoints, which happens more and more often these days. And yeah, as I guessed, this is not a bug in the code, automated attack attempt. So the actual recommendation by Cloud Code in this case is resolve or smooth it in
And also, of course, you can do that right away from cloud code, because again, it's using Flare MCP. So yeah, with the MCP launched back in 2025, this is the block article by Trek, and with
the CLI introduced later in 2026, Flare is totally ready for AI agents to fix your bugs after they appear. And also, I see they have 10-day trial, no credit card required.
So yeah, why not try Flare? Thank you, Sparky, for sponsoring this video. Now let's get back to the topic of this video and in addition to new event form I asked Cloud Code to generate this page called bug lab.
So five potential bugs that may appear if you don use the package if you just rely on form request So imagine you have starts at and then you need to reformat that timestamp date time
to something else to send in an email, reminder email, which may be in different formats, time zones, or may need other carbon operations. So, with DTO, you have proper carbon immutable or carbon object.
if you try to use this in just form request. After validation, it will fail because, well, it's a string. The second potential bug is an enum. So, for example, in the legacy controller, you saw that I'm doing enum from,
so I'm doing that here in the controller, but what if somewhere else in some service afterwards the same data is needed, and then you may forget to cast it to enum again, and then you may have that type error because format is not enum and some service class expects
the enum to be passed. Again, with validated DTO, that format becomes an enum object. Next, the Boolean part is public. If, for example, you need to perform some operation with isPublic,
for example, show the text somewhere or publish the event somewhere, if you, again, use it with DTO, you can safely do the check, because DTO is boolean. If it's not boolean, if it's a string,
then this would fail. If it is not passed, it is empty, you will have PHP error. Then another potential bug and another feature that I haven't mentioned yet is DTO within DTO. So you have
event DTO and then, for example, ticket tier DTO inside of the same thing. So, for example, event data tickets first will work with DTO, but will not work because of the type error
in case of this one. And then another example, if the input field has different name from database column, for example, in this case. So if you need, for example, promo code and a database should be promotion code or vice versa, again, you can transform it with DTO class. And it's not
possible that easy to automate with simple code you have to basically transform it manually in the controller and elsewhere so this is what may happen basically the idea is to have again one
single class that defines the rules now let me show you that class in more details so create event dto extends validated dto and these are other cast classes that will be used here so first
we define the properties, and as you can see, property type is very important, obviously, so we have enum here, we have carbon immutable, we have boolean, and then we have other DTOs. So venue DTO is also extending validated DTO so this is the parent relationship that I showed you with its own properties validation rules like form requests and CAS if needed
Now let's get back to the main create event DTO. So basically a lot of properties, some of them, as you can see, optional. Then we have rules, which is typical form request, nothing really different here.
So we have array validation, we have enum validation. So all the same stuff. Then we have defaults. So this is what is protecting from data missing. There will be default values here.
So if you don't specify isPublic, it will default to false. And then other defaults. Then casts. You saw that above already. So additional casting to Boolean or array or correction or string.
Then validation messages. Again, we'll get back to form request. Attributes is also form request. typical thing and then this not to transform for the case of different as I said input name and
database column name you may transform it like this so yeah to summarize Validator DTO is a great package if you want to have single source of truth for other operations after form request so
this is defined in the official docs if the same operation or operations after form request may also run elsewhere from a queue, job console command, model action service class or elsewhere
that DTO still becomes the source of true with casting everything to appropriate classes. And by the way if you're not that familiar with the concept DTO data transfer object and there's also value object I have a few tutorials on Laravel daily they are pretty
old 2022, 2024 and 2025 and also this package is listed in the search results we'll link that in the description below, because the concept of DTO and value object hasn't changed since then,
it's been around since forever, it's just that in PHP, historically, there was no enforcement of strict types, it became, of course, better in the later versions, and Laravel started to enforce
that and generated return types and stuff like that by default, but package like this one from Lendl gives additional swiftness, which is needed if you care about your data to be in the correct shape no matter where you call that data object from. What do you think about this package? I think
it's very important for Sirius especially if you work with like array of arrays, strict structure like importing CSE for example or creating database object from form with parent child like event or
invoice or stuff like that. I think you should try it out. Let's discuss in the comments below what you think or if you tried this package or if you tried DTOs in general. Let's discuss all of that in the comments. That's it for this time and see you guys in other videos.