<commit_before># Value

is a pico library (or code snippets shed) to help you to __easily implement Value Types__ in your C# projects without making errors nor polluting your domain logic with boiler-plate code.
[![Build status](https://ci.appveyor.com/api/projects/status/ju5m6t3fm2xsl0o9/branch/master?svg=true)](https://ci.appveyor.com/project/tpierrain/value/branch/master)

![Value](https://github.com/tpierrain/Value/blob/master/Value-small.jpg?raw=true)

## Value Types?
__Domain Driven Design (DDD)__'s *Value Object* being an oxymoron (indeed, an object has a changing state by nature), we now rather use the "*Value Type*" (instance) terminology. But the concept is the same as described within Eric Evan's Blue book.

__A Value Type:__
 - is __immutable__ (every field must be read-only after the Value Type instantiation; no 'setter' is allowed)
 - is __rich with domain logic and behaviours__. The idea is to swallow (and encapsulate) most of our business complexity within those classes
 - embraces the __Ubiquitous Language__ of our business context: cure to primitive obsession, the usage of Value Types is an opportunity for us to embrace the language of our business within our code base
 - __exposes, uses and combines functions__ to provide business (domain) value. Functions usually return new instance(s) of Value Types ('*closure of operations*' describing an operation whose return type is the same as the type of its argument(s))

```c#
    // e.g.: the following Add function does not change any existing Amount instance, it just returns a new one
    public Amount Add(Amount otherAmount) 
```

 - __considers ALL its attributes for Equality and Uniqueness__ (and "all" *is-a-must* here)
 - is __auto-validating__ (via *transactional* constructors __with business validation inside__ and throwing exception if necessary)


### Reverse the trend! (we need more Value Types, and fewer Entities)

An *Entity* is an object that has a changeable state (often made by combining Value Objects) for which we care about its identity. Whether to use an Entity or Value Object will strongly depend on your business context (*there is no silver bullet*). Here are some basic samples to better grasp the difference between *Value Types* and *Entities*:<commit_msg>Add appveyor CI badge within the readme.md<commit_after>[![Build status](https://ci.appveyor.com/api/projects/status/ju5m6t3fm2xsl0o9/branch/master?svg=true)](https://ci.appveyor.com/project/tpierrain/value/branch/master)

# Value

is a pico library (or code snippets shed) to help you to __easily implement Value Types__ in your C# projects without making errors nor polluting your domain logic with boiler-plate code.

![Value](https://github.com/tpierrain/Value/blob/master/Value-small.jpg?raw=true)

## Value Types?
__Domain Driven Design (DDD)__'s *Value Object* being an oxymoron (indeed, an object has a changing state by nature), we now rather use the "*Value Type*" (instance) terminology. But the concept is the same as described within Eric Evan's Blue book.

__A Value Type:__
 - is __immutable__ (every field must be read-only after the Value Type instantiation; no 'setter' is allowed)
 - is __rich with domain logic and behaviours__. The idea is to swallow (and encapsulate) most of our business complexity within those classes
 - embraces the __Ubiquitous Language__ of our business context: cure to primitive obsession, the usage of Value Types is an opportunity for us to embrace the language of our business within our code base
 - __exposes, uses and combines functions__ to provide business (domain) value. Functions usually return new instance(s) of Value Types ('*closure of operations*' describing an operation whose return type is the same as the type of its argument(s))

```c#
    // e.g.: the following Add function does not change any existing Amount instance, it just returns a new one
    public Amount Add(Amount otherAmount) 
```

 - __considers ALL its attributes for Equality and Uniqueness__ (and "all" *is-a-must* here)
 - is __auto-validating__ (via *transactional* constructors __with business validation inside__ and throwing exception if necessary)


### Reverse the trend! (we need more Value Types, and fewer Entities)

An *Entity* is an object that has a changeable state (often made by combining Value Objects) for which we care about its identity. Whether to use an Entity or Value Object will strongly depend on your business context (*there is no silver bullet*). Here are some basic samples to better grasp the difference between *Value Types* and *Entities*:
{'fraction_non_alphanumeric': 0.0708678587003925, 'fraction_numerical': 0.0026166593981683385, 'mean_word_length': 4.813688212927756, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 6, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '848158', 'n_tokens_mistral': 1229, 'n_tokens_neox': 1181, 'n_words': 616}