В Domain Driven Design, когда объект клонирует себя, кто добавляет его в свой контейнер?

Question

Например, у нас есть два предметных объекта: Клетка и Тело (как в клетке и теле человека).

Класс Body - это просто набор ячеек, например

class Body
{
    IList<Cell> cells;
    public void AddCell(Cell c) { ... }
    public void RemoveCell(Cell c) { ... }
}

Ячейка имеет метод Split, который внутренне создает свой клон, например,

Class Cell
{
    public Cell Split()
    {
        Cell newCell = new Cell();
        // Copy this cell's properties into the new cell.
        return Cell;
    }
}

Теперь, в DDD, когда ячейка расщепляется, следует:

1. Клетка добавляет вновь созданную ячейку в тело (что будет означать, что каждый объект ячейки содержит ссылку на свое содержащее тело)?
2. Или должен ли сервисный уровень, получивший первоначальный запрос пользователя, вызвать Split, собрать возвращенную ячейку и добавить ее в тело? (похоже на более анемичный дизайн с использованием контроллеров, а не объектов домена)
3. Или тело должно содержать метод SplitCell?

Заранее спасибо.

Answer 1

Я думаю, что Body просто вызовет splitCell () для Cell. Тогда Тело может делать то, что хочет с новой Клеткой - добавлять к себе, потреблять, выбрасывать, что угодно. Тело в любом случае содержит клетку.

Answer 2

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

Если ваш внешний актер не знает о теле, должен ли метод Split вернуть новый клон Cell? Будет ли внешний актер использовать это как-нибудь? Или же метод Split не может ничего вернуть (Void) и просто отправить сообщение в тело, в котором он живет?

Answer 3

Использование событий в классе Cell кажется естественным решением, но реализовать его на C # сложнее.

Вам нужно будет подключать события, когда Cells входит в область видимости, и вам также нужно отсоединять их, когда они выходят за пределы области видимости - иначе вы получите утечки памяти.

Вам также необходимо подключать события всякий раз, когда ячейка повторно связывается с Body, т.е. когда ячейки извлекаются из хранилища постоянства. Использование контейнера для управления отношениями (возможно, перехватчик ORM) может упростить это.

Более простая альтернатива - хранить ссылку на родителя Body (ячейки принадлежат только одному Body, верно?), И позволить новому Cell добавить себя в его Body.

• Плюсы: легко кодировать, отлаживать, понимать.
• Минусы: ячейка и тело становятся тесно связанными, что затрудняет их повторное использование в других контекстах (что может быть неактуально)

Answer 4

В DDD это часто зависит от домена. Здесь пример - и, следовательно, домен - кажется немного странным, но я думаю, что я бы пошел на SplitCell метод на Body.

Хотя мне не очень понятно, что означает расщепление клеток и что должно вызвать это действие, я полагаю, что тело отвечает за расщепление своих клеток. Мне было бы удобнее использовать метод Regenerate или что-то подобное на Body, который разбивает внутренние ячейки, вызывая метод Split для каждого из них.

Хорошо, этот пример совершенно странный ...

Answer 5

После прочтения Domain Driven Design (Evans) может показаться, что этот сценарий лучше всего решать с помощью сервиса .