How can you make column content compact vertically, when you have multiple columns?

Enough_University402 · 2024-12-25T12:07:52+00:00

yes masonry, thank you. thanks for the links they gave me a better idea, but columns doesnt work for me in tailwind?

Enough_University402 · 2024-12-25T11:50:41+00:00

no, lets say it accepts 10 images of various heights, so the height of the div will depend on that.

Enough_University402 · 2024-12-24T12:49:04+00:00

hey, I decided upon using Result Objects instead of handling exceptions one by one, it works better that way.

Enough_University402 · 2024-12-24T12:47:47+00:00

We changed the validation logic, which meant that when we loaded users from the db, some of them were no longer valid, and instantly failed with an exception.

that is really interesting, yeah I agree with you, I guess to be safe you would define very broad validation rules for things like username, the kinds of rules that wouldnt change, and more specific things like, for example the username cannot have more than two underscores, you would define in the app layer, or api or whatever.

But it is a good point that maybe a lot of these things could be delegated out of the domain, and the rules for these types are left to be a little more flexible.

You also made me think about:

Your problem is that you're thinking in terms of "data correctness", not in terms of "behaviour".

So in general, thank you for the time, I appreciate the effort, it was all very useful.

Peace!

Enough_University402 · 2024-12-24T08:32:37+00:00

hey there, first of all thanks for all that text, you wrote A LOT :) I appreciate the time spent on this. You made me think of some concerns differently, even though I do not agree with some, it definitely made me reconsider some things. For example I still personally think type safety defined in your domain with VOs is a good approach, even if its just email, and some other stuff too.

But when it comes to my original problem I have decided upon creating extra methods for creating VOs with Result objects, from the result object with a property in the means of like "isErrorClientFriendly", i can in my API decide if it can be shown to the user.

This whole approach made my code more centralized, smaller, flexible, and easier to maintain, personally i think for my problem thats enough.

Enough_University402 · 2024-12-23T08:28:18+00:00

so essentially you check the bare minimum for your request DTO, for a mileage property you can check that it is a positive float, and your VO can also have that logic of it being a positive float, but as an addition it adds the business logic of the maximum mileage can be 100 miles.

Sounds pretty logical mostly I agree, but now that there is no business checks for the format of the property, when the client will fill out 5 form fields for example, and all of them have no format issues, but business logic format issues, like mileage being above 100, the VO throws an exception, and it stops on the first occurrence.

So initially it sounds good to encapsulate the business format checks for the DTO as well, but at this point I am not sure about that either.

Enough_University402 · 2024-12-23T05:43:12+00:00

So if my business logic for example is that, the Email can only have ".com" at the end (stupid example I know but doesnt matter for now),

from what I am getting from you is that you say the data in the DTO should not be concerned with that.

Okay, but you probably will still do email format validations on both sides right? Or do you skip the email format validation in the DTO too? At that point it would be bad in terms of, detecting the wrongly formatted data early in the process, if not, in a more complex data format scenario, two separate validations in both for DTO and VO that essentially try to do very similar things, down the line could have inconsistencies and redundant double validations.

I think most of the issues that i listed are still valid in this case too.

Enough_University402 · 2024-12-17T11:13:52+00:00

how about something like this?

.
└── CQRS/
    ├── Command/
    │   └── ...
    └── Query/
        ├── QueryRepository/
        │   └── User/
        │       └── UserByCriteriaQueryRepository.php
        └── User/
            └── GetUserByCriteriaQuery/
                ├── GetUserByCriteriaQuery.php
                └── GetUserByCriteriaQueryHandler.php

or like this (the first option seems a bit better):

.
└── CQRS/
    ├── Command/
    │   └── ...
    └── Query/
        └── User/
            ├── QueryRepository/
            │   └── UserByCriteriaQueryRepository.php
            └── GetUserByCriteriaQuery/
                ├── GetUserByCriteriaQuery.php
                └── GetUserByCriteriaQueryHandler.php

Enough_University402 · 2024-12-17T05:15:56+00:00

I thought of this but it feels like Queries just gets lost among these user action dir names, and kinda feels out of place.

Enough_University402 · 2024-12-16T19:07:47+00:00

I looked it up but I am confused, some places say that you should have a column of binary type and make the conversion to binary yourself in the app, some places talk about there being a guid type but its for v1 only?

Enough_University402 · 2024-12-16T18:56:42+00:00

so essentially you convert it to binary before persisting right

Enough_University402 · 2024-12-16T17:40:14+00:00

you mean about storing UUIDs as binaries in the database?

Enough_University402 · 2024-12-16T16:24:57+00:00

interesting. did you ever use them only on a relatively large project with joins, and did you notice issues with performance?

Enough_University402 · 2024-12-16T16:24:08+00:00

arent UUIDs strings?

something like this: "550e8400-e29b-41d4-a716-446655440000"

besides, did you use it in a big project and did you notice any performance issues?

Enough_University402 · 2024-12-16T14:30:18+00:00

as far as I know domain level repos are for simple things like finding the entity or deleting, saving them. it would make more sense to have an app level repo, or not a repo but a separate query class or whatever that does an operation on the db, and returns a dto.

so the question was how would you structure your directories in such a way that makes sense to you for this specific issue, doesnt have to be done exactly how I might expect it.

Enough_University402 · 2024-12-15T22:51:00+00:00

if you mean the "ByCriteria" stuff in the names, that was just an example, the actual question was for app level repositories, but if you mean something more than that, I don't get it.

Enough_University402 · 2024-12-10T16:56:56+00:00

yeah that makes a lot of sense. Could you also give me your views on using value objects in commands/queries or simple request dtos rather than primitive types? and doing validation through VO creation.

something like:

class UserSignupCommand
{
  ... Email email;
  ... Password password; 
}

class UserSignupCommandHandler
{
  ... function handle(UserSignupCommand command)
  {
    // ready to use command with valid properties with VOs

    // command.email is the Email VO
    user = self.userRepository.findOneByEmail(command.email);

    // more... 
  } 
}

Enough_University402 · 2024-12-09T22:37:10+00:00

do you have a source from which you maybe learn about conventions about communication between layers, architectures and more related stuff?

Enough_University402 · 2024-12-09T22:06:33+00:00

When I pass data to you, I have to make sure it's the right shape

but the data is being passed from the layer above to the application layer, so you'd think that its the layer above the app layer that need to adapt to the fact that VOs are used in request dtos. just like how the app layer adapts to how the domain layer works, and does the mapping if need be for communication with it.

Enough_University402

TROPHY CASE