<h1>Why This Project Exists</h1>
<h2>Formal Domain Modeling Inspired by Mathematical Functions</h2>
<hr>
<h2>1. The Original Motivation</h2>
In mathematics, every function is defined over a domain.
For example:
f(x) = sqrt(x)
Domain: x ≥ 0
The function is not defined outside its domain.
However, in most software systems, we declare variables like this:
<pre><code>int age;
decimal price;
string username;
</code></pre>
Formally, these types have extremely wide domains:
<ul>
<li><code>int</code> → [-2,147,483,648 … 2,147,483,647]</li>
<li><code>decimal</code> → ±7.9 × 10²⁸</li>
<li><code>string</code> → virtually unlimited</li>
</ul>
But in real-world logic, we almost never mean that.
<hr>
<h2>2. The Real Problem</h2>
Consider:
<pre><code>int age;
</code></pre>
Mathematically, the type allows:
age ∈ ℤ
But in reality:
age ∈ [0, 120]
Yet nothing in the type system enforces that.
This leads to:
<ul>
<li>Implicit assumptions</li>
<li>Scattered validation</li>
<li>Repeated boundary checks</li>
<li>Hidden domain rules</li>
<li>Invalid states possible at runtime</li>
</ul>
The variable type does not reflect its true mathematical domain.
<hr>
<h2>3. The Core Idea</h2>
Instead of declaring:
<pre><code>int age;
</code></pre>
We define formally:
Age ∈ [0, 120]
Instead of:
<pre><code>string username;
</code></pre>
We define:
Username ∈ Strings(3…10)
The project was created to model:
Value ∈ Domain
explicitly and formally.
<hr>
<h2>4. What This Project Does</h2>
The system separates:
Concept Responsibility
<hr>
Domain Defines valid set
Value Holds data
Policy Defines behavior when invalid
Extensions Enable functional composition
This reflects mathematical rigor inside software modeling.
<hr>
<h2>5. Why Not Just Validate?</h2>
Traditional validation looks like this:
<pre><code>if (age &lt; 0 || age &gt; 120)
 throw new Exception();
</code></pre>
But this approach:
<ul>
<li>Scatters validation across code</li>
<li>Couples validation to usage</li>
<li>Allows invalid values to exist temporarily</li>
<li>Repeats logic in multiple places</li>
</ul>
Domain modeling centralizes the rule once and for all.
<hr>
<h2>6. Mathematical Thinking Applied to Code</h2>
Instead of thinking:
<blockquote>
“This is an int.”
</blockquote>
We think:
<blockquote>
“This value belongs to a specific mathematical set.”
</blockquote>
Examples:
<ul>
<li>Percentage ∈ [0, 100]</li>
<li>Temperature ∈ [-50, 150]</li>
<li>Latitude ∈ [-90, 90]</li>
<li>Money ∈ [0, +∞) with scale 2</li>
</ul>
The project enforces those domains structurally.
<hr>
<h2>7. Benefits Achieved</h2>
<h3>7.1 No Invalid States</h3>
You cannot accidentally create:
Age = -10
Percentage = 150
Username = “”
Money = -500
unless the domain allows it.
<hr>
<h3>7.2 Explicit Domain Semantics</h3>
The type now expresses intent:
<pre><code>DCValue&lt;int&gt; age;
</code></pre>
means:
age ∈ DefinedDomain
The rule is no longer implicit.
<hr>
<h3>7.3 Reusable Mathematical Domains</h3>
Domains become reusable objects:
<pre><code>var ageDomain = new NumericDomain&lt;int&gt;(0, 120);
var percentDomain = new NumericDomain&lt;int&gt;(0, 100);
</code></pre>
Domain logic is not duplicated.
<hr>
<h3>7.4 Functional Composition</h3>
Using <code>Map</code> and <code>Bind</code>, transformations become pipelines:
Raw Input → Domain Validation → Transformation → Output
This mirrors functional mathematical composition.
<hr>
<h2>8. Why This Matters</h2>
Primitive obsession is common in software:
<ul>
<li>Everything is <code>int</code></li>
<li>Everything is <code>string</code></li>
<li>Everything is <code>decimal</code></li>
</ul>
But real systems have semantics.
By modeling domains explicitly, the code moves closer to:
<ul>
<li>Formal reasoning</li>
<li>Predictability</li>
<li>Mathematical clarity</li>
<li>Stronger invariants</li>
</ul>
<hr>
<h2>9. Money as a Case Study</h2>
Money is not:
decimal amount;
It is:
Money ∈ [0, +∞), scale = 2, currency-bound
That is a mathematical structure, not just a primitive.
The project applies domain rigor even to financial modeling.
<hr>
<h2>10. Final Philosophy</h2>
This project was written because:
<ul>
<li>Primitive types are mathematically too permissive.</li>
<li>Real-world values belong to constrained sets.</li>
<li>Domain constraints should be structural, not optional.</li>
<li>Validation should be centralized.</li>
<li>Invalid states should be impossible or explicit.</li>
</ul>
In short:
<blockquote>
Software variables should behave more like mathematical variables.
</blockquote>
<hr>
Project is her on github:
<a href="https://github.com/vicvondoom/DomainWrapper" target="_blank" rel="noopener nofollow">https://github.com/vicvondoom/DomainWrapper</a>
I’m not pretending that something like this doesn’t already exist, I hope I’ve introduced something interesting.

All about .NET, C#, and ASP.NET Core. News, tutorials, articles, projects, and more. 

.NET

A C# library that enforces domain constraints at the type level, inspired by mathematical function domains. Instead of using primitive types like `int` or `string` with implicit validation scattered throughout code, it models values as belonging to explicitly defined mathematical sets (e.g., Age ∈ [0, 120]). The approach centralizes validation logic, prevents invalid states from existing, and enables functional composition through Map/Bind operations. The library separates domain definitions from values and policies, making constraints structural rather than optional.

A Domain wrapper in C#