DDD: подклассы и корневые объекты
Идеальное решение состояло бы в том, чтобы использовать inline-block для столбцов вместо плавания. Я думаю, что поддержка браузера довольно хороша, если Вы следуете (a) применяются inline-block только к элементам, которые обычно встроены (например, span); и (b) добавляют -moz-inline-box для Firefox.
Проверка Ваша страница в FF2 также, потому что у меня была тонна проблем, когда вложенные определенные элементы (удивительно, это - один случай, где IE работает намного лучше, чем FF).
3 ответа
Я думаю, вы начинаете терять большую часть гибкости системы, создавая конкретные типы этих сущностей. Тип отношения, который вы подразумеваете, - это то, что я обычно передаю с сущностью «Тип». Например, у вас есть машина. Феррари - это разновидность автомобилей. Две сущности, порождаемые этим, - это Car и CarType.
Как вы говорите, вам придется добавлять новые сущности каждый раз, когда вводится новый тип. Если все, что вы пытаетесь зафиксировать, - это «прозвище» автомобиля, я бы подумал, что это просто еще один фрагмент данных, а не другая сущность. Если у вас нет разных данных (то есть разных имен свойств) и / или различий в поведении сущностей Car для разных типов, вы не получите многого от этого подхода. Я бы предпочел использовать методы репозитория, такие как FindCarByType (), и работать с одним типом сущностей, чтобы снизить риск.
Я ни в коем случае не эксперт DDD, и я борюсь с некоторыми концепциями (или больше похож на борьбу с множественными интерпретациями некоторых концепций). Я обнаружил, что не существует 100% чистой реализации, и что в каждой реализации, которую я видел, есть нюансы.
Edit Follows
Я вижу, что неправильно прочитал часть того, что вы написали. Я вижу, что это прозвище не для всех автомобилей, а только для Ferrari: Автомобиль. Я думаю, что ответ на самом деле - «смотря по обстоятельствам». Насколько сильно доменная специализация у вас в остальной части вашей модели? Прозвище может быть распространено среди компаний Ferrari, но является ли оно эксклюзивным? Дело не только в фактических данных, но и в требованиях.
Вы не должны использовать наследование для моделирования своего домена, потому что вы скоро столкнетесь с проблемами, как только модель начнет усложняться.
Президент - это просто роль человека, и человек может иметь несколько роли. Может быть, президент получил только одну роль, но это просто случайность из-за неправильного выбора.
Ferrari тоже не следует унаследовать от автомобиля. На примере Ferrari это не очевидно, потому что они делают только один тип автомобилей, но рассматривают компанию, производящую множество типов, таких как фургоны, седаны, хэтчбеки, грузовики и так далее. Вы, вероятно, захотите создать классы для каждого типа, который будет унаследован от класса car. И что потом ... вы собираетесь создать пять классов Toyota, которые будут унаследованы от каждого типа? Например ...
Car -> Sedan -> ToyotaSedan
Car -> Truck -> ToyotaTruck
Car -> Hatchback -> ToyotaHatchback
Это было бы смешно.
Отказ от ответственности: Я ничего не знаю об автомобилях. Однако ...
Дон ' t использовать наследование для моделирования своего домена. Всегда.
Попробуйте без наследования, и также станет очевидно, как сохранить ваш домен.
Обычно, когда вы пересекаете границы корневого агрегата, вы разрешаете ссылаться только на идентификатор другого корневого агрегата. Затем вы используете этот идентификатор для поиска другого агрегата в его репозитории.
Итак, в вашем случае вы хотите, чтобы у президента был идентификатор автомобиля, и если вам когда-либо понадобится что-то сделать с автомобилем президента, вы должны использовать идентификатор автомобиля для зайти в репозиторий, чтобы получить машину. У президента не будет упоминания о самой машине.
Теперь о Ferrari. Это довольно сложно обеспечить в стандартной терминологии DDD. Обычно вы ставите некоторую оценку присвоению автомобиля президенту. Или, возможно, есть служба CarBuyingService только для президентов, которая гарантирует, что вы все сделаете правильно. Обычно в DDD специализации не являются корневыми агрегатами.