Is it possible to have multiple primatives with Vogen?

[danielmackay]

I'm just starting to explore Vogen and so far am really liking it. I'm also trying to see how far I can push the library. 😄

In DDD, a Value Object doesn't just have to be a single value. A Value Object could be a collection of values.

Is it possible to do something like this?

[ValueObject<decimal, string>]
public partial struct Money;

Where decimal would be the amount, and string would be a currency code.

[SteveDunn]

Thanks for the feedback. Yes, Vogen is for simple (singular) value objects rather than composites.

I feel there is some other library that could represent composite value objects, potentially using Vogen to represent the individual components.

[SteveDunn]

Records are a reasonable choice. Perhaps with an analyser similar to Vogen's that catches default initialisation (and optionally that all parameters are value objects)

[danielmackay]

Cheers for the reply.

Yeah, I had a play around with a few options and records are the same conclusion I came to.

For example:

// records give us structural equality by default
public record Address
{
    // immutable (can't use `with` keyword when properties are defined like this)
    public string Street { get; }
    public string City { get; }
    public string State { get; }

    public Address(string street, string city, string state)
    {
        // always valid
        ArgumentException.ThrowIfNullOrWhiteSpace(street);
        ArgumentException.ThrowIfNullOrWhiteSpace(city);
        ArgumentException.ThrowIfNullOrWhiteSpace(state);

        Street = street;
        City = city;
        State = state;
    }

    // behavior
    public bool IsInState(string state) => State == state;
}

By using a record like this we tick all the boxes for a value object (immutable, structural equality, always valid), without allowing validation rules to be bypassed via language features (e.g. with syntax).

You can find the other options I explored here: https://github.com/danielmackay/dotnet-value-objects

[SteveDunn]

It's the ambiguity in the constructors that bothers me. The compiler can't help with mistakes as they're all primitives. When not using value objects, I tend to use init properties as it forces initialisation to specify names.

Perhaps this future (imaginary) package could be semi opinionated:

• No constructors
• No new/default
• Records only
• All properties are init only
• All properties are value objects