RFC: Domain Traits expansion in LanguageExt

[HernanFAR]

RFC: Domain Traits expansion in LanguageExt — DomainType, Factories, Rules, Units of Measure, and realistic samples

Hi everyone 👋

We are opening this discussion to gather feedback on a significant expansion of domain modelling support in LanguageExt. If you are affine to Domain Driven Design, you know the important that domain concepts have. They are ment to live as real types, with explicit invariants, always valid, etc.

Language-Ext already has a minimal set of domain traits. And I found them useful, but they can be better. Most of this work is product of using those existing domain traits. By segreggating interfaces and/or expanding them on the higher-kind world, this proposal introduces a richer vocabulary for expressing those concepts while staying within C# and LanguageExt.

General mental model

The core idea is to separate separate domain models in 3 pounts that are often mixed together.

1. Types
2. Factories
3. Invariants (or rules, as they are named in code)

1. What is this value?

This is answered by DomainType<SELF> family of traits. They are representation of domain concepts, but as typed classes, structs or record. Examples:

• UserName
• Email
• UserId
• Money
• WorkDuration
• WorkMoment

Each one represents a domain idea, not just a wrapper over a primitive.

2. How is a valid value created?

This is answered by DomainFactory<SELF, TYPE, FROM> family of traits. They are the way that a primitive or another type is taken and mapped to a valid value,

Factories construct values in a explicit, controlled and faillable way. through Fin<T> and ```FinT<M, T>.

If you have used to current domain-traits, you might see something, the current DomainType<SELF, REPR> serves as a DomainType and DomainFactory trait's!

3. What must be true for it to be valid?

This is answered by Rule<SELF, TYPE> trait family. With rules you explicitly can create invariants, and even can create generalized invariants that you can reuse in different entities, aggregate roots or use cases in code.

They are a way to create reusable and composable set of pre-conditions, instead of scattering logic around clases

Conceptual flow

The 3 points come together in this sample flow:

External data
    ↓
DomainFactory / DomainFactoryM
    ↓
Rules
    ↓
DomainType
    ↓
Valid domain value
    ↓
Safer composition

System boundaries can remain flexible, but once values enter the domain, the rest of the code can operate on meaningful validated values.

What is new?

To show the new traits, I'll add commets, so this isn't too big to start

[HernanFAR]

Domain Type traits

Here we will go over all the traits, and as a didactic sample, we are going to build something with the trait we are reviewing and aggregate on each one of them

If the trait in review modifies a class,. we will write the implementation again, with the differences

1. DomainType<SELF>

DomainType is the conceptual base for domain types. It answers:

“What is this value in the domain?”

It is defined as

public interface DomainType<SELF> 
    where SELF : DomainType<SELF>;

Code samples

public sealed record User : DomainType<User>;

public class Sample
{
    public static void Main()
    {
        var user = new User();
    }
}

2. DomainType<SELF, REPR> and DomainRepresent<REPR>

The trait aims to provide a REPR To() (via DomainRepresent interface) method that exposes internal representation of a DomainType<SELF>. It works like the current implementation of DomainType:

• UserName -> string
• UserId -> int
• Money -> decimal
• Date -> DateOnly

But, unlike the current implementation, the responsibility of DomainType is meaning and representation. It should not be responsible for validating external input or deciding how a valid value is constructed.

That separation avoids turning a domain type into a mix of:

• representation
• parsing
• validation
• configuration access
• ID generation

This is not nessesary bad, I must say. The code includes an equivalent, it is called DomainTypeFactory<SELF, REPR>, but the core idea of DomainType is just represent and meanify a domain concept.

What it resolves

The main problem that resolves, is to bring a direct access to the representation of the Domain Type, because if you have an Entity that different layers of value objects that wraps and validades primitives, you know how tedious is access all of the underlying values.

Is better to do var email = user.To() rather than var email = user.Email.To(), and event more if you are using five properties.

Definition

public interface DomainRepresent<REPR>
{
    REPR To();
}

public interface DomainType<SELF, REPR> :
    DomainType<SELF>,
    DomainRepresent<REPR>
    where SELF : DomainType<SELF, REPR>;

Samples

public sealed record EmailAddress : DomainType<EmailAddress, string>
{
    private readonly string _value;

    public EmailAddress(string value)
    {
        if (!value.Contains('@'))
        {
            throw new InvalidOperationException();
        }

        _value = value;
    }

    public string To() => _value;
}

public sealed record User : 
    DomainType<User, string>
{
    public required EmailAddressType Email { get; init; }

    private User(EmailAddressType email) =>
        Email = email;

    public string To() =>
        Email.To();
}

public class Sample
{
    public static void Main()
    {
        var baseEmail = new EmailAddress("pruebas@concepto.cl");

        var user = new User(baseEmail);
        
        var email = user.To();
    }
}

3. Derived<SELF, BASE> and DerivedType<SELF, BASE, REPR>

This trait represents the diference between a Something and a VerifiedSomething. It brings the same content and representation of an already existing DomainType, but with a hat, and that hat removes any other property to specify specific semantics in a type.

What it resolves

Most of the time, when we have value objects that aren't specific enoght, we complement these types with boolean or enum flags. That isn't bad, but is we have 3 flags to specify something of one or many propertis, maybe is time to move that flags to the respecting types

Short code sample of this

Instead of having

public sealed record EmailAddress : DomainType<EmailAddress, string>
{
    private readonly string _value;

    public EmailAddress(string value)
    {
        if (!value.Contains('@'))
        {
            throw new InvalidOperationException();
        }

        _value = value;
    }

    public string To() => _value;
}

public sealed record User(UserId Id, EmailAddress Email, bool EmailVerified)

public static class Program
{
  public static void Main()
  {
     var user = new User(...);

     if (user.EmailVerified) continue;

     MethodThatDoesSomething(user.Email); 
  }
  
  public static void MethodThatDoesSomethingf(EmailAddress)
  {
    // something
  }
}

We can use

/// <summary>
/// Email address Discriminated Union
/// </summary>
public interface EmailAddressType : DomainRepresent<string>;

public sealed record EmailAddress : 
    EmailAddressType,
    DomainType<EmailAddress, string>
{
    private readonly string _value;

    public EmailAddress(string value)
    {
        if (!value.Contains('@'))
        {
            throw new InvalidOperationException();
        }

        _value = value;
    }

    public string To() => _value;
}

public sealed record VerifiedEmailAddress : 
    EmailAddressType,
    DomainType<VerifiedEmailAddress, string>
    DerivedType<VerifiedEmailAddress, EmailAddress, string>
{
    private readonly EmailAddress _value;

    public VerifiedEmailAddress(EmailAddress value) =>
        _value = value;

    public EmailAddress ToBase() => _value;

}

public sealed record UnverifiedEmailAddress : 
    EmailAddressType,
    DomainType<UnverifiedEmailAddress, string>
    DerivedType<UnverifiedEmailAddress, EmailAddress, string>
{
    private readonly EmailAddress _value;

    public UnverifiedEmailAddress(EmailAddress value) =>
        _value = value;

    public EmailAddress ToBase() => _value;

}

public sealed record User(UserId Id, IEmailAddress Email, bool EmailVerified)

public static class Program
{
  public static void Main()
  {
     var user = new User(...);

     // This won't even compile, because  user.Email is IEmailAddress, not UnverifiedEmailAddress
     MethodThatDoesSomething(user.Email); 
     
     if (user.Email is VerifiedEmailAddress unverifiedEmailAddress) continue;

     MethodThatDoesSomething(unverifiedEmailAddress); 
  }
  
  public static void MethodThatDoesSomethingf(UnverifiedEmailAddress)
  {
    // something
  }
}

Definition

public interface Derived<SELF, BASE> : DomainType<SELF>
    where SELF : Derived<SELF, BASE>
    where BASE : DomainType<BASE>
{
    BASE ToBase();
}

public interface DerivedType<SELF, BASE, REPR> : 
    Derived<SELF, BASE>, 
    DomainType<SELF, REPR>
    where SELF : DerivedType<SELF, BASE, REPR>
    where BASE : DomainType<BASE, REPR>
{
    REPR DomainType<SELF, REPR>.To() =>
        ToBase().To();
}

Completed code sample aggregate

Completed code sample aggregate

/// <summary>
/// Email address Discriminated Union
/// </summary>
public interface EmailAddressType : DomainRepresent<string>;

/// <summary>
/// Email address trait-type
/// </summary>
public interface EmailAddressType<SELF> :
    EmailAddressType,
    DomainType<SELF, string>
    where SELF : EmailAddressType<SELF>;
    
// Main value objects representing EmailAddresses
public sealed record EmailAddress : EmailAddressType<EmailAddress>
{
    private readonly string _value;

    public EmailAddress(string value) 
    {  
        if (!value.Contains('@'))
        {
            throw new InvalidOperationException();
        }

        _value = value;
    }

    public string To() => _value;
}

public sealed record VerifiedEmailAddress :
    EmailAddressType<VerifiedEmailAddress>,
    DerivedType<VerifiedEmailAddress, EmailAddress, string>
{
    private readonly EmailAddress _value;

    public VerifiedEmailAddress(EmailAddress value) =>
        _value = value;

    public EmailAddress ToBase() => _value;

}

public sealed record UnverifiedEmailAddress :
    EmailAddressType<UnverifiedEmailAddress>,
    DerivedType<UnverifiedEmailAddress, EmailAddress, string>
{
    private readonly EmailAddress _value;

    public UnverifiedEmailAddress(EmailAddress value) =>
        _value = value;

    public EmailAddress ToBase() => _value;

}

public sealed record User(EmailAddressType Email) : 
    DomainType<User, string>
{
    public string To() =>
        Email.To();
}

public class Sample
{
    public static void Main()
    {
        // DomainType
        var baseEmail = new EmailAddress("pruebas@concepto.cl");

        // DomainType
        var user1 = new User(baseEmail);
        var user3 = new User(new VerifiedEmailAddress(baseEmail));
        
        // DomainRepresent
        var email = user.To();
    }
}

4. Refined<SELF, BASE>

This trait represents a more specific version of an existing DomainType. It is used to extend or constrict a type, rather than act like a wrapper. By it self, works more like a marker, but when we introduce DomainFactories, it will make more sense.

What it resolves

This types resolves the problem of having specific invariants applied in a type, without leaving a specific spece of work to do comparations between related types

Length is used to refer anything that is measurable in a single dimensional space, yet you need a specific subset of valid values of Length to model the concept of "Height", because can't exists negative Height, but it can exists negative Length

Refined works to apply a validation to an domain type that is too board to represent a domain concept, but differs from Derived in the sense that Derived is the same but with a hat.

Definition

public interface Refined<SELF, BASE> : Derived<SELF, BASE>
    where SELF : Refined<SELF, BASE>
    where BASE : DomainType<BASE>;
    
public interface RefinedType<SELF, BASE, REPR> :
    Refined<SELF, BASE>,
    DomainType<SELF, REPR>
    where SELF : RefinedType<SELF, BASE, REPR>
    where BASE : DomainType<BASE>;

Completed code sample aggregate

Complete code sample aggregate

/// <summary>
/// Email address Discriminated Union
/// </summary>
public interface EmailAddressType : DomainRepresent<string>;

/// <summary>
/// Email address trait-type
/// </summary>
public interface EmailAddressType<SELF> :
    EmailAddressType,
    DomainType<SELF, string>
    where SELF : EmailAddressType<SELF>;

public sealed record EmailAddress : EmailAddressType<EmailAddress>
{
    private readonly string _value;

    public EmailAddress(string value)
    {
        if (!value.Contains('@'))
        {
            throw new InvalidOperationException();
        }

        _value = value;
    }

    public string To() => _value;
}

public sealed record VerifiedEmailAddress :
    EmailAddressType<VerifiedEmailAddress>,
    DerivedType<VerifiedEmailAddress, EmailAddress, string>
{
    private readonly EmailAddress _value;

    public VerifiedEmailAddress(EmailAddress value) =>
        _value = value;

    public EmailAddress ToBase() => _value;

}

public sealed record User(EmailAddressType Email) :
    DomainType<User, string>
{
    public string To() =>
        Email.To();
}

public sealed record VerifiedUser
    : RefinedType<VerifiedUser, User, string>
{
    private readonly User _user;

    public VerifiedEmailAddress Email { get; init; }

    public VerifiedUser(User user)
    {
        if (user.Email is not VerifiedEmailAddress email)
        {
            throw new Exception();
        }

        Email = email;

        _user = user;
    }

    public User ToBase() => _user;

    public string To() => _user.To();
}

public class Sample
{
    public static void Main()
    {
        // DerivedType
        var baseEmail = new EmailAddress("pruebas@concepto.cl");
        var verifiedEmail = new VerifiedEmailAddress(baseEmail);

        // DomainType
        var standardUser = new User(verifiedEmail);

        // RefinedType
        var verifiedUser = new VerifiedUser(standardUser);

        // DomainRepresent
        var email = verifiedUser.To();
    }
}

5. Identifier<SELF> and IdentifierType<SELF, REPR>

By combining ``DomainTypeandDiscreteSpace``` (An algebraic type that defines sets) we got Identifiers, representings things like Ids.

What it resolves

Identifiers aren't just wrappers around a primitive, they are values that have a unique identity based on the underlying representation, so this traits solves the necesity to specify that unique identity

Definition

public interface Identifier<SELF> : 
    DomainType<SELF>,
    DiscreteSpace<SELF>
    where SELF : Identifier<SELF>;
    
public interface IdentifierType<SELF, REPR> : 
    Identifier<SELF>, 
    DomainType<SELF, REPR>
    where SELF : IdentifierType<SELF, REPR>;

Completed code sample aggregate

Samples

/// <summary>
/// Email address Discriminated Union
/// </summary>
public interface EmailAddressType : DomainRepresent<string>;

/// <summary>
/// Email address trait-type
/// </summary>
public interface EmailAddressType<SELF> :
    EmailAddressType,
    DomainType<SELF, string>
    where SELF : EmailAddressType<SELF>;

/// <summary>
//  Email address deriving trait-type, alias of implementing  EmailAddressType<SELF>, DerivedType<SELF, EmailAddress, string>
/// </summary>
/// <remarks>
/// Usually this trait specification is not necessary, but serves as a sample of how reduce code if a concept keeps repeting, like in this case
/// </remarks>
public interface DerivedEmailAddressType<SELF> :  
    EmailAddressType<SELF>,
    DerivedType<SELF, EmailAddress, string>
    where SELF : DerivedEmailAddressType<SELF>;
    
public sealed record EmailAddress : EmailAddressType<EmailAddress>
{
    private readonly string _value;

    public EmailAddress(string value)
    {
        if (!value.Contains('@'))
        {
            throw new InvalidOperationException();
        }

        _value = value;
    }

    public string To() => _value;
}

public sealed record VerifiedEmailAddress : DerivedEmailAddressType<VerifiedEmailAddress>
{
    private readonly EmailAddress _value;

    public VerifiedEmailAddress(EmailAddress value) =>
        _value = value;

    public EmailAddress ToBase() => _value;

}

public sealed record UserId : IdentifierType<UserId, string>
{
    private readonly string _value;

    public UserId(string value)
    {
        if (string.IsNullOrEmpty(value))
        {
            throw new Exception();
        }

        _value = value;
    }

    public string To() => _value;
}

public sealed record UserRepr(string Id, string Email);

/// <summary>
/// User Discriminated Union
/// </summary>
public interface UserType : DomainRepresent<UserRepr>;

/// <summary>
/// User trait-type
/// </summary>
public interface UserType<SELF> :
    UserType,
    DomainType<SELF, UserRepr>
    where SELF : UserType<SELF>;

/// <summary>
/// User refining trait-type, alias of implementing
/// <see cref="UserType{SELF}"/> and
/// <see cref="DerivedType{SELF, BASE, REPR}"/> with BASE as
/// <see cref="User"/> and REPR as <see cref="UserRepr"/>
/// </summary>
/// <remarks>
/// Usually this trait specification is not necessary, but serves as a sample of how reduce code if a concept keeps repeating,
/// </remarks>
public interface RefinedUserType<SELF> :
    UserType<SELF>,
    RefinedType<SELF, User, UserRepr>
    where SELF : RefinedUserType<SELF>;
    
public sealed record User(UserId Id, EmailAddressType Email) :
    UserType<User>
{
    public UserId Id { get; } = Id
    
    public UserRepr To() => new (Id.To(), Email.To());
}

public sealed record VerifiedUser : RefinedUserType<VerifiedUser>
{
    private readonly User _user;

    public UserId Id => _user.Id;

    public VerifiedEmailAddress Email { get; init; }

    public VerifiedUser(User user)
    {
        if (user.Email is not VerifiedEmailAddress email)
        {
            throw new Exception();
        }

        Email = email;

        _user = user;
    }

    public User ToBase() => _user;

    public UserRepr To() => _user.To();
}

public class Sample
{
    public static void Main()
    {
        // DerivedType
        var baseEmail = new EmailAddress("pruebas@concepto.cl");
        var verifiedEmail = new VerifiedEmailAddress(baseEmail);

        // Identifier
        var userId = new UserId("ABC");

        // DomainType
        var standardUser = new User(userId, verifiedEmail);

        // RefinedType
        var verifiedUser = new VerifiedUser(standardUser);

        // DomainRepresent
        var (id, email) = verifiedUser.To();
    }
}

6. Magnitude<SELF, SCALE>, MagnitudeType<SELF, SCALE, REPR> and MagnitudeType<SELF, REPR>

By combining ``DomainTypeandVectorSpace``` (An algebraic type that defines sets) we got magnitudes, They representes types that moves around in vector space, meaning that they work with adding, subtracting with SELF, but multipling and diving with scalar.

What they resolve

This traits allow to easily implement vector spaces operations of a domain type, like lengths! Most of the systems need to do math stuff with money, areas, etc; so this allows to set a start-point for these types.

The Units of Measure folder insider LanguageExt.Core has many implementations of Magnitude, so I'll skip an custom implementation.

Definition

public interface Magnitude<SELF, SCALAR> :
    DomainType<SELF>,
    VectorSpace<SELF, SCALAR>,
    IComparable<SELF>,
    IComparisonOperators<SELF, SELF, bool>
    where SELF : Magnitude<SELF, SCALAR> 
    where SCALAR : notnull;
   
public interface MagnitudeType<SELF, SCALAR, REPR> :
    DomainType<SELF, REPR>,
    Magnitude<SELF, SCALAR> 
    where SELF : MagnitudeType<SELF, SCALAR, REPR> 
    where SCALAR : notnull;
    
public interface MagnitudeType<SELF, REPR> : 
    MagnitudeType<SELF, REPR, REPR>
    where SELF : MagnitudeType<SELF, REPR>
    where REPR : notnull;

Completed code sample aggregate

Completed code sample aggregate

/// <summary>
/// Email address Discriminated Union
/// </summary>
public interface EmailAddressType : DomainRepresent<string>;


/// <summary>
/// Email address trait-type
/// </summary>
public interface EmailAddressType<SELF> :
    EmailAddressType,
    DomainType<SELF, string>
    where SELF : EmailAddressType<SELF>;

/// <summary>
/// Email address deriving trait-type, alias of implementing
/// <see cref="EmailAddressType{SELF}"/> and
/// <see cref="DerivedType{SELF, BASE, REPR}"/> with BASE as
/// <see cref="EmailAddress"/> and REPR as <see cref="string"/>
/// </summary>
/// <remarks>
/// Usually this trait specification is not necessary, but serves as a sample of how reduce code if a concept keeps repeating,
/// </remarks>
public interface DerivedEmailAddressType<SELF> :
    EmailAddressType<SELF>,
    DerivedType<SELF, EmailAddress, string>
    where SELF : DerivedEmailAddressType<SELF>;

public sealed record EmailAddress : EmailAddressType<EmailAddress>
{
    private readonly string _value;

    public EmailAddress(string value)
    {
        if (!value.Contains('@'))
        {
            throw new InvalidOperationException();
        }

        _value = value;
    }

    public string To() => _value;
}

public sealed record VerifiedEmailAddress : 
    DerivedEmailAddressType<VerifiedEmailAddress>
{
    private readonly EmailAddress _value;

    public VerifiedEmailAddress(EmailAddress value) =>
        _value = value;

    public EmailAddress ToBase() => _value;

}

public sealed record UserId : IdentifierType<UserId, string>
{
    private readonly string _value;

    public UserId(string value)
    {
        if (string.IsNullOrEmpty(value))
        {
            throw new Exception();
        }

        _value = value;
    }

    public string To() => _value;
}

public sealed record Height : RefinedType<Height, Length, double>
{
    private readonly Length _value;

    public Height(Length value)
    {
        if (value.To() > 0)
        {
            throw new Exception();
        }

        _value = value;
    }

    public Length ToBase() => _value;

    public double To() => _value.Metres;
}

public sealed record UserRepr(string Id, string Email, double HeightInMeters);

/// <summary>
/// User Discriminated Union
/// </summary>
public interface UserType : DomainRepresent<UserRepr>;

/// <summary>
/// User trait-type
/// </summary>
public interface UserType<SELF> :
    UserType,
    DomainType<SELF, UserRepr>
    where SELF : UserType<SELF>;

/// <summary>
/// User refining trait-type, alias of implementing
/// <see cref="UserType{SELF}"/> and
/// <see cref="DerivedType{SELF, BASE, REPR}"/> with BASE as
/// <see cref="User"/> and REPR as <see cref="UserRepr"/>
/// </summary>
/// <remarks>
/// Usually this trait specification is not necessary, but serves as a sample of how reduce code if a concept keeps repeating,
/// </remarks>
public interface RefinedUserType<SELF> :
    UserType<SELF>,
    RefinedType<SELF, User, UserRepr>
    where SELF : RefinedUserType<SELF>;

public sealed record User(
    UserId Id, 
    EmailAddressType Email,
    Height Height) 
    :
    UserType<User>
{
    public UserId Id { get; } = Id;

    public UserRepr To() => new(Id.To(), Email.To(), Height.To());
}

public sealed record VerifiedUser : RefinedUserType<VerifiedUser>
{
    private readonly User _user;

    public UserId Id => _user.Id;

    public VerifiedEmailAddress Email { get; init; }

    public Height Height => _user.Height;

    public VerifiedUser(User user)
    {
        if (user.Email is not VerifiedEmailAddress email)
        {
            throw new Exception();
        }

        Email = email;

        _user = user;
    }

    public User ToBase() => _user;

    public UserRepr To() => _user.To();
}

public class Sample
{
    public static void Main()
    {
        // DerivedType
        var baseEmail = new EmailAddress("pruebas@concepto.cl");
        var verifiedEmail = new VerifiedEmailAddress(baseEmail);

        // Identifier
        var userId = new UserId("ABC");

        // Magnitude
        var length = 175 * UnitsOfMeasure.cm;

        // RefinedType
        var userHeight = new Height(length);

        // DomainType
        // Even if this user complies, it will throw an exception
        // when instantiating VerifiedUser
        var standardUser = new User(userId, baseEmail, userHeight);

        // RefinedType
        // With allows us to update only the Email property, so it won't throw
        var verifiedUser = new VerifiedUser(standardUser with
        {
            Email = verifiedEmail
        });

        // DomainRepresent
        var (id, email, heightInMeters) = verifiedUser.To();
    }
}

7. Maintainer<SELF> and MaintainerType<SELF, REPR>

By combining ``DomainTypeandDiscreteSpace``` , apart of Identifiers we got Maintainer, they represent closed set of already know values.

What thet resolve

When you need to specify a kind for a type of account, the types of account are already existing, and most of the time, extend the list means new bussiness rules that implies more development. This traits allows to have all related values in a splot, and allows easy use of them, via methods like Find, FindM

Definition

public interface Maintainer<SELF> :
    DomainType<SELF>,
    DiscreteSpace<SELF>
    where SELF : Maintainer<SELF>
{
    static abstract Seq<SELF> All { get; }
}

public interface MaintainerType<SELF, REPR> :
    Maintainer<SELF>,
    DomainType<SELF, REPR> 
    where SELF : MaintainerType<SELF, REPR>;

Completed code sample aggregate

Completed code sample aggregate

```C# ///

/// Email address Discriminated Union ///

public interface EmailAddressType : DomainRepresent;

///

/// Email address trait-type
///

public interface EmailAddressType :
EmailAddressType,
DomainType<SELF, string>
where SELF : EmailAddressType;

///

/// Email address deriving trait-type, alias of implementing
/// and
/// with BASE as
/// and REPR as
///

///
/// Usually this trait specification is not necessary, but serves as a sample of how reduce code if a concept keeps repeating,
///
public interface DerivedEmailAddressType :
EmailAddressType,
DerivedType<SELF, EmailAddress, string>
where SELF : DerivedEmailAddressType;

public sealed record EmailAddress : EmailAddressType
{
private readonly string _value;

public EmailAddress(string value)
{
    if (!value.Contains('@'))
    {
        throw new InvalidOperationException();
    }

    _value = value;
}

public string To() => _value;

}

public sealed record VerifiedEmailAddress :
DerivedEmailAddressType
{
private readonly EmailAddress _value;

public VerifiedEmailAddress(EmailAddress value) =>
    _value = value;

public EmailAddress ToBase() => _value;

}

public sealed record UserId : IdentifierType<UserId, string>
{
private readonly string _value;

public UserId(string value)
{
    if (string.IsNullOrEmpty(value))
    {
        throw new Exception();
    }

    _value = value;
}

public string To() => _value;

}

public sealed record Height : RefinedType<Height, Length, double>
{
private readonly Length _value;

public Height(Length value)
{
    if (value.To() > 0)
    {
        throw new Exception();
    }

    _value = value;
}

public Length ToBase() => _value;

public double To() => _value.Metres;

}

public sealed record UserKind : MaintainerType<UserKind, string>
{
private readonly string _value;

public static UserKind Basic { get; } = new("Basic");

public static UserKind Premium { get; } = new("Premium");

public static Seq<UserKind> All { get; } =
[
    Basic, 
    Premium
];

private UserKind(string value) =>
    _value = value;

public string To() => _value;

}

public sealed record UserRepr(
string Id,
string Email,
double HeightInMeters,
string Kind);

///

/// User Discriminated Union
///

public interface UserType : DomainRepresent;

///

/// User trait-type
///

public interface UserType :
UserType,
DomainType<SELF, UserRepr>
where SELF : UserType;

///

/// User refining trait-type, alias of implementing
/// and
/// with BASE as
/// and REPR as
///

///
/// Usually this trait specification is not necessary, but serves as a sample of how reduce code if a concept keeps repeating,
///
public interface RefinedUserType :
UserType,
RefinedType<SELF, User, UserRepr>
where SELF : RefinedUserType;

///

/// When you create an user, you can modify Email and Height
/// properties, but Id is read-only once created
///

///
/// Because you might update values, is a record the
/// is very useful.
///
public sealed record User(
UserId Id,
EmailAddressType Email,
Height Height)
:
UserType
{
public UserId Id { get; } = Id;

public UserKind Kind => UserKind.Basic;

public UserRepr To() => 
    new(Id.To(), Email.To(), Height.To(), Kind.To());

}

///

/// A verified user is strictly readonly, so we only have direct
/// accessors of get-only properties
///

///
/// Because you can't update values, is a class, so you can't even
/// use is very useful.
///
public sealed class VerifiedUser : RefinedUserType
{
private readonly User _user;

public UserId Id => _user.Id;

public VerifiedEmailAddress Email { get; }

public Height Height => _user.Height;

public UserKind Kind => UserKind.Premium;

public VerifiedUser(User user)
{
    if (user.Email is not VerifiedEmailAddress email)
    {
        throw new Exception();
    }

    Email = email;

    _user = user;
}

public User ToBase() => _user;

public UserRepr To() => _user.To() with
{
    Kind = Kind.To()
};

}

public class Sample
{
public static void Main()
{
// DerivedType
var baseEmail = new EmailAddress("pruebas@concepto.cl");
var verifiedEmail = new VerifiedEmailAddress(baseEmail);

    // Identifier
    var userId = new UserId("ABC");

    // Magnitude
    var length = 175 * UnitsOfMeasure.cm;

    // RefinedType
    var userHeight = new Height(length);

    // DomainType
    // Even if this user complies, it will throw an exception
    // when instantiating VerifiedUser
    var standardUser = new User(userId, baseEmail, userHeight);

    // RefinedType
    // With allows us to update only the Email property
    var verifiedUser = new VerifiedUser(standardUser with
    {
        Email = verifiedEmail
    });

    // DomainRepresent
    var (id, email, heightInMeters, kind) = verifiedUser.To();
}

}

</details>

[louthy]

Hi, I'm glad that you are so engaged with the project, but I'm really not happy with the approach you are taking with this. I made it clear the first time you tried to commit a change the domain system that I wasn't sure that that was the correct approach. And I'm still not happy with what you're doing. Trying to force the situation by harvesting opinion rather than discussing with myself is not a good approach (as well as saying "we" like its something that is sanctioned by me, is really not a good look).

Just to be clear the best way to get buy-in for any feature, is to discuss it with me first via this forum; not to bulldoze the process by constantly submitting PRs, closing them, reopening and closing them reopening them. Causing lots of email notifications for the users of this repo.

The core idea of the domain system was to be a very light and a very specific set of interfaces for some very precise definitions. The direction you're taking it is not precise and it is too opinionated and this library is not about reflecting those opinions on others' domains.

I am not even sure whether I'm going to keep the domain types in the final release as I think I explained to you before. So building on top of something that I'm not even sure is going to be in the final release is really not a good idea.

So I'm going to be closing your PRS. I'm gonna be closing this thread. Because it's not for this repo.

May I suggest that you create yourself a new nuget package and publish it yourself with all of the reasoning and documentation you like (please don't prefix the package with 'LanguageExt.' as I'm trying to get ownership of the prefix at the moment). If you send me the link, i'll add it to the wiki.

I'm sorry if this seeks harsh, it'd be much less painful if you'd just started a discussion. So please consider that in the future.