title: How to deal with optional data in a typed domain model?
body: <p>When developing applications / domain models in general, I am wondering what would be the best way <strong>to deal with incomplete or optional data</strong>.
  Typed languages such as <em>TypeScript</em> and <em>C#</em> give us the power of <strong>typing our models</strong>. Sometimes this is powerful, as it put constraints on our model and can force it to be integer.
  However, usually, real-life data is <strong>incomplete</strong> and that appears to reduce the advantages of typing constraints drastically.</p>
  
  <p>Imagine a simple data model in a sample application (TypeScript frontend and some backend) of an entity called <em>Project</em> which has an <em>id</em>, a <em>name</em> and an optional <em>description</em>. The data is retrieved from a backend.</p>
  
  <p>The data model is defined in the frontend using interfaces:</p>
  
  <pre class="lang-js prettyprint-override"><code>export interface IProject {
      id: number;
      name: string;
      description: string;
  }
  
  </code></pre>
  
  <p>The data is retrieved from the backend as follows:</p>
  
  <pre class="lang-js prettyprint-override"><code>export class ProjectService {
      public getProject(projectId: number): Observable&lt;IProject&gt; {
          const url = 'http://server/api/project/' + projectId;
          return this.httpClient.get&lt;IProject&gt;(url);
      }
  }
  </code></pre>
  
  <p>Example response of a project which actually has a description.</p>
  
  <pre><code>{
      "id": 1
      "name": "My first project",
      "description": "My first project is just a demo"
  }
  </code></pre>
  
  <p>In the frontend application we display the retrieved data. For example, let's display the first 10 characters of the project description.</p>
  
  <pre><code>alert(project.description.substr(0,10));
  </code></pre>
  
  <p>So far, everything fine. </p>
  
  <p>But imagine that our user created "Project two" without filling in the optional description. Now the backend can respond with:</p>
  
  <pre><code>{
      "id": 2
      "name": "Project two"
  }
  </code></pre>
  
  <p>or</p>
  
  <pre><code>{
      "id": 2
      "name": "Project two",
      "description" : null
  }
  </code></pre>
  
  <p>Now we get a null-reference exception in the frontend: <strong>Cannot read property 'substr' of null</strong>.
  Of course it's possible to add an if statement that checks for the description to be null:</p>
  
  <pre><code>if(project.description) {
    alert(project.description.substr(0,10));
  }
  </code></pre>
  
  <p>This works, but it means adding null checks across the whole application. The whole code base would be full with those checks, along with the dangers of masking bugs instead of preventing them. That just does not feel right to me.</p>
  
  <p>A possible solution could be to always return a description, hence returning an empty string if none was filled in.</p>
  
  <pre><code>{
      "id": 2
      "name": "Project two",
      "description": ""
  }
  </code></pre>
  
  <p>Now the frontend does not need null checks for description any more, but it is no longer possible to distinguish between an <em>explicitly</em> filled-in empty description and a <em>not(-yet)</em> filled-in description.</p>
  
  <p>What is the best way to deal with these kind of problems? The example above is just to illustrate, the scope is quite generic. It seem to plague all typed languages in which a <strong>typed</strong> contract/interface is defined which cannot always be fulfilled.</p>