In DDD, are entities allowed to use the database for search, indexing etc.?

Question

It is (was?) considered best practices when it come to web programming to let the database do the 'heavy lifting', when possible. For example, I have a contact list, and it consists of many emails addresses and name. Each email must be unique, so one potentially bad solution for an active record model (Eloquent) is this case will be:

 public function addEmail($name, $address)
 {
    if ($this->where('name', $name)->where('address', $address)->count() > 0)
  {
  throw new \Exception("Name and email already exists!");
  }

 // perform add new logic

 }

If what I have understood is correct, I shouldn't be doing this -- that the entities should be plain data objects, and unable to make calls out to the DB.

In that case, how should I enforce that bit of validation? Use a service, or load in all the addresses for the ContactList, or move it somewhere else (an AddNewEmailToConactList service?)

Answer 1

You have a look at the business-rules that govern your domain, and you find the one that will cause you a problem, and you validate it at the point where you might break it.

So if the rule is There can be no duplicate email addresses in the contact list then you would validate it when you add the new Entry to the ContactList.

The ContactList itself will most likely have a method AddNewEntry which will do the check, and the ContactList either is or has a database table that it can query to check if the name already exists.

It's perfectly valid to have multiple copies of the same email addresses in this case; they just can't all go on the ContactList. There could even be multiple ContactLists in which case the above code would still work, with each list checking its own contents. But it really depends on the exact domain you're working from.