Имеется сущность "Клиент" (Customer). Клиент может иметь 1 номер мобильного телефона и 1 адрес электронной почты. Телефонный номер, как и адрес электронный могут быть в двух состояниях - "Не подтвержден" и "Подтвержден". Забегая вперед, скажу, что все эти 4 параметра должны храниться в одной таблице Customers, дабы избежать лишних JOIN'ов.
Мой главный вопрос: как смоделировать доменную модель?
Атрибуты PhoneNumber и IsPhoneNumberConfirmed (как и Email и IsEmailConfirmed) выглядят так, как будто выражают нечто целое. Можно было бы определить ValueObject Communication с двумя параметрами Value и IsConfirmed. Тогда, класс Customer мог выглядеть бы так:
public class Customer
{
public Communication Phone { get; private set; }
public Communication Email { get; private set; }
}
Но как быть с тем фактом, что IsConfirmed это по сути - состояние объекта (что, если я не ошибаюсь, противоречит концепции ValueObject)?
Наверное, было бы удобно с точки зрения API определить метод Communication.Confirm(), который изменит состояние IsConfirmed на true. Что, опять же противоречит концепции ValueObject (VO должен быть неизменяемым после создания).
Возможно это Entity? Тогда эти объекты должны хранится в отдельных таблицах в БД? Это противоречит тому, что описал в начале ("...все эти 4 параметра должны храниться в одной таблице Customers").
Может быть, я сделал неверное предположение, что атрибуты PhoneNumber и IsPhoneNumberConfirmed должны является частью одного объекта?
Может быть, метод подтверждения средства связи должен находится в классе клиента: Customer.ConfirmMobilePhone()? Ведь, это клиент подтверждает телефон, а не телефон подтверждает сам себя.
Сборка персонального компьютера от Artline: умный выбор для современных пользователей