ValueObject - too wordy?

Question

So, I'm having some value objects in my domain, and when I'm using them in one of my builders it looks like this:

.withSomething(Id.of(123), Specifiers.of(MySpecifier.of("233"), MySpecifier.of("23423")));

and in method I have:

withSomething(Id id, Specifiers specifiers){
  //id.value()...
}

This seems too wordy for my taste, as it can be written as:

.withSomething(123, "233", "23423");

and then in method I would have:

withSomething(int id, String... specifiers){
    Id.of(id);
    Specifiers.of(specifiers);
}

First one seems more descriptive but today IDEs can also mark variable names - so it would be shown like this:

.withSomething(id: 123, specifiers: "233", "23423");

Which of these 2 approaches you use and why?

Answer 1

Horses for Courses.

withSomething(Id id, Specifiers specifiers){
    // ...
}

withSomething(int id, String... specifiers) {
    withSomething(Id.of(id), Specifiers.of(specifiers));
}

There are a few tensions at work; we do want an API that is easy to use (and easy to test), but we don't want to encourage primitive obsession, and we prefer that data validation happen as close to the I/O boundary as we can manage.

I try to resolve those tensions by using a primitive wrapper around the domain specific implementation. These methods will often be in different objects - the implementation of the primitive api composed out of its domain specific cousin.

does this means you are basically doing method overloading in classes where it is needed?

Or composition:

class BadlyNamedBuilder {
    withSomething(Id id, Specifiers specifiers){
        // ...
    }
}

class BadlyNamedAdapter {
    BadlyNamedBuilder builder;

    withSomething(int id, String... specifiers) {
        builder.withSomething(Id.of(id), Specifiers.of(specifiers));
    }
}

Answer 2

I normally use jargons like withSomething() in implementation of Builder pattern to build value object but not in value object itself. Either approach is fine for me. My rule of thumb is, is it readable and doesn't look complicated to the weakest/freshest member of my team.