title: External id as domain identity
body: <p>Our application sends/receives a lot of data to/from a third party we work with.<br>
  Our domain model is mainly populated with that data.</p>
  
  <p>The 'problem' we're having is identifying a 'good' candidate as <strong>domain identity</strong> for the aggregate.</p>
  
  <p>It seems like we have 3 options:<br></p>
  
  <ol>
  <li><strong>Generate</strong> a domain identity (<code>UUID</code> or <code>DB-sequence</code>...);</li>
  <li><strong>Use the External-ID as domain identity</strong> that comes along with all data from the external source.</li>
  <li><strong>Use an internal domain identity AND External-ID as a separate id</strong> that 'might' be used for retrieval operations; the internal id is always leading</li>
  </ol>
  
  <p>About the External-ID:</p>
  
  <ul>
  <li>It is 100% guaranteed the ID will <strong>never change</strong></li>
  <li>The ID is always <strong>managed</strong> by the <strong>external</strong> source</li>
  <li><strong>Other domains</strong> in our system <strong>might use the external-id</strong> for retrieval operations</li>
  </ul>
  
  <p>Especially the last point above convinced us that the external-id is not an infrastructural concern but really belongs to the domain.</p>
  
  <p>Which option should we choose?</p>
  
  <p>** <strong>UPDATE</strong> **</p>
  
  <p>Maybe I was not clear about the term '3th party'.<br>
  Actually, the external source is our client who is active in the Car industry.<br> Our application uses client's master data to complete several 'things'. We have several Bounded Contexts (BC) like <em>'Client management'</em>, <em>'Survey'</em>, <em>'Appointment'</em>, 
  <em>'Maintenance'</em> etc. <br><br>
  Our client sends us 'Tasks' that describe <em>something</em> needs te be done.
  That 'something' might be:</p>
  
  <ul>
  <li>'let client X complete survey Y'</li>
  <li>'schedule/cancel appointment for client X'</li>
  <li>'car X for client Y is scheduled for maintenance at position XYZ'</li>
  </ul>
  
  <p>Those 'Tasks' always have a 'task-id' that is guaranteed to be unique.
  We store all incoming 'Tasks' in our database (active record style). Every possible action on a task maps with a domain event. (Multiple BCs might be interested in the same task)</p>
  
  <p>Every BC contains one or more aggregates which distribute some domain events to other BCs. For instance, when an appointment is canceled a domain event is triggered, maintenance listens to that event to get some things done. <br></p>
  
  <p>However, our client expects some message after every action that is related to a Task. Therefore we always need to use the 'task-id'.</p>
  
  <p>To summarize things:</p>
  
  <ul>
  <li>Tasks have a task-id </li>
  <li>Tasks might be related to multiple BCs</li>
  <li>Every BC sends some 'result message' to the client with the related task-id</li>
  <li>Task-ids are distributed by domain events</li>
  <li>We keep every (internally) persisted task up-to-date</li>
  </ul>
  
  <p><br>
  Hopefully, I was clear enough about the use of the external-id (= task-id) and our different BCs.</p>