Есть два варианта.
Первый заключается в том, чтобы выгружать из БД всю коллекцию тегов. В данном случае такое решение будет вполне оправданным. Поскольку обычно задачи, и вообще что-либо, содержат 3-5 тегов, максимум 7-10, очень редко больше. В таком случае вполне нормально сделать свойство Tags у сущности Task и ожидать, что там будут всегда все теги данной задачи. Т.е. всегда загружать коллекцию тегов для задачи при восстановлении задачи из БД.
Второй заключается в том, чтобы вынести логику в Service. CA и подобные архитектуры диктуют лишь то, что бизнес логика (БЛ) должна быть первична, а все остальное вторично и подстраивается под БЛ. Но они не ограничивают в средствах выражения, т.е. необязательно чтобы вся БЛ была в методах сущностей. Наоборот, внутри сущностей должна быть лишь простая логика, а все что посложнее выносится в Domain Service-ы.
Например, можно создать TaskService, в котором будет метод AddNewTagToTask(Tag tag, Task task). Так как это сервис, то здесь можно иметь зависимость на соответствующий репозиторий, и тогда можно проверить наличие тега с помощью него: if (!taskRepository.TaskHaveTag(tag)) { ... }
Второй подход применяют когда связная коллекция очень большая, тысячи и более элементов. В таком случае это вообще единственный вариант.
Но стоит заметить, что если выбран второй подход, то стоит убрать свойство Tags из сущности Task. Так как это будет обманом. Представьте, что вы решили не загружать все теги для задачи, а сделать проверку через сервис. Но в проекте вы работаете не один. Другой же программист увидит что есть поле Tags у задачи и попытается использовать его так, как-будто там там содержатся все теги для задачи. Поэтому чтобы не создавать двусмысленности нужно убрать свойство Tags из Task.
