Базовые классы "Entity" и "ValueObject" в управляемом доменом дизайне

Question

Всегда ли вы создаете эти два абстрактных базовых класса в качестве основы для любого нового проекта в DDD?

Я читал, что у Entity должно быть две вещи.Во-первых, свойство тождественности, возможно, универсального типа.Во-вторых, метод Equals (), который определяет, совпадает ли он с другим объектом.Что-нибудь еще?Любые другие естественные методы или эмпирические правила?

Answer 1

Мне нравится иметь общего абстрактного предка для всех моих объектов Домена, но это вопрос предпочтений и общих требований к инфраструктуре.

После этого, да, у меня есть абстрактные классы для объектов Entity и Value.

Не забывайте, что переопределение Equals для объектов Value для возврата равенства на основе состояния равных свойств может быть важным.

Также люди часто упускают из виду ценность пакетов.Поместите все эти базовые базовые классы в их собственную библиотеку «ядра» и не стесняйтесь разделять модель вашего домена на несколько сборок, вместо того, чтобы сводить одну большую «Библиотеку доменов».

Answer 2

Если вы используете .NET / C #, я опубликовал набор интерфейсов и классов DDD для публичного использования.Посмотрите, что обычно происходит внутри них.Комментарии во встроенном коде должны указывать на их использование.

Вы можете [скачать его здесь] [1]. Проект сейчас мертв.

Answer 3

До сих пор мне никогда не требовался метод Equals () в моих приложениях.Ваш пробег может отличаться.

Однако я создаю пустые интерфейсы и использую их как дескрипторы:

public interface IAggregateRoot {}
public interface IEntity {}
public interface IValueObject {}

public class Order : IAggregateRoot
{
  ...
}

public class State : IValueObject
{
  ...
}