Raw strings in domain-driven applications should be replaced with value objects to prevent bugs and improve type safety; 1. Using raw strings leads to primitive obsession, where interchangeable string types can cause subtle bugs like argument swapping; 2. Value objects such as EmailAddress encapsulate domain-specific strings with validation, immutability, and meaningful semantics; 3. Benefits include type safety, centralized validation, immutability via records, better discoverability, and consistent formatting; 4. Helper methods like IsCorporate can be added for domain logic; 5. Modern language features like C# records reduce boilerplate, while implicit operators and value conversions in ORMs like EF Core support seamless interop; 6. Normalization ensures consistent formatting, and serialization libraries can handle these types via custom converters; 7. Source generators can automate repetitive code, making adoption easier; 8. Starting small with critical types like Email or PhoneNumber demonstrates clear benefits in clarity, correctness, and maintainability, proving that domain-specific strings deserve dedicated types.

When working with strings in domain-driven applications, it’s easy to treat them as raw, interchangeable values — assigning them freely between variables, parameters, and database fields. But this leads to subtle bugs, poor type safety, and code that’s hard to reason about. A modern, more robust approach is to treat domain-specific strings as value objects.

Instead of using string directly for things like email addresses, phone numbers, or IDs, we wrap them in dedicated types. This gives us better correctness, clarity, and control.

Why Raw Strings Are Problematic

Using plain strings everywhere may seem harmless, but consider this:

string userId = "jane.doe@example.com";
string email = "12345";
SendEmail(email, userId);

Wait — did we just swap the arguments? The compiler won’t catch this. Both are string, so they’re interchangeable, even though they represent very different concepts.

This is the primitive obsession code smell: over-relying on built-in types instead of modeling domain concepts.

Value Objects to the Rescue

A value object represents a meaningful piece of domain data defined by its value, not identity. For strings, this means wrapping them in a lightweight, immutable type that enforces rules.

For example, an EmailAddress value object:

public record EmailAddress(string Value)
{
    public static bool TryParse(string input, out EmailAddress? email)
    {
        email = null;
        if (string.IsNullOrWhiteSpace(input)) return false;

        try
        {
            var addr = new System.Net.Mail.MailAddress(input);
            if (addr.Address == input)
            {
                email = new EmailAddress(input.Trim());
                return true;
            }
        }
        catch { }

        return false;
    }

    public override string ToString() => Value;
}

Now, instead of:

void SendEmail(string to, string from)

We have:

void SendEmail(EmailAddress to, EmailAddress from)

The function signature now means something. You can’t accidentally pass a user ID where an email is expected.

Benefits of Domain-Specific String Types

• Type Safety: The compiler prevents mixing different kinds of strings.
• Encapsulation: Validation logic lives in one place — the value object.
• Immutability: Records (in C#) or similar constructs ensure the value doesn’t change.
• Discoverability: IDEs can suggest PhoneNumber, SSN, etc., making APIs easier to use correctly.
• Consistency: All instances follow the same rules (formatting, normalization, etc.).

You can also add helpers:

public bool IsCorporate() => Value.EndsWith("@company.com", StringComparison.OrdinalIgnoreCase);

Common Patterns and Optimizations

While creating a new type per string may feel verbose, modern languages reduce the overhead:

• C# records provide Equals, GetHashCode, and immutability for free.
• Implicit/explicit operators (use sparingly) can ease interop:

public static implicit operator string(EmailAddress email) => email.Value;

But be cautious — implicit conversions can bring back the original problem if overused.

Alternatively, expose .Value only when needed (e.g., for serialization), keeping the domain model strict.

Also consider normalization:

public record Username(string Value)
{
    public Username() : this("guest") { }
    public Username(string value) : this(value?.Trim().ToLowerInvariant() ?? "guest") { }
}

This ensures consistent formatting across the system.

Framework and Ecosystem Support

Modern ORMs (like EF Core) support value conversions to map value objects to database columns:

modelBuilder.Entity<User>()
    .Property(u => u.Email)
    .HasConversion(e => e.Value, s => EmailAddress.Parse(s));

Serialization libraries (System.Text.Json, Newtonsoft) can also be taught to handle these types via converters.

And with source generators or Roslyn analyzers, you can even auto-generate boilerplate for common patterns (e.g., a NonEmptyString base type).

Final Thoughts

Treating domain-specific strings as value objects isn’t just academic — it prevents bugs, improves maintainability, and makes your code express intent clearly.

Start small: pick one critical string (like Email or PhoneNumber) and wrap it. Once you see the benefits — fewer bugs, clearer APIs, self-documenting code — you’ll wonder why you didn’t do it sooner.

It’s not about eliminating strings; it’s about giving them meaning.

Basically, if a string represents a concept in your domain, it deserves a type.

The above is the detailed content of Strings as Value Objects: A Modern Approach to Domain-Specific String Types. For more information, please follow other related articles on the PHP Chinese website!