Ядоблог

Размышления о применимости DDD (Domain Driven Design) для веб проектов не дают покоя.
Сразу оговорюсь, что рассуждения касательно применимости не в энтерпрайз, а в своих мелких проектикиках.

Попробую систематизировать размышления, т.к. текущее состояние мыслей похоже на это в центральной стадии:

1. принцип DDD — проектируем модель, а затем думаем как сохранять. Хорошо, если модель легко проектируется на место хранения…
Возможно у меня кривое представление модели, но, под моделью(MVC, DDD) я понимаю большой жирный слой, в котором нужно реализовать следующее:

Интерфейсы, реализация классов объектов(геттеры, сеттеры). Связи между объектами пока опустим.
Обычно не сложно.

Сохранением объектов занимаются мапперы. Проектируем интерфейс маппера и реализуем по 1 мапперу на каждый класс объекта. Что-то простое плоское сохранять и извлекать легко. Идеологически, в коллекциях MongoDB правильно хранить агрегаты. Агрегаты — это сложные объекты, имеющие не плоскую структуру(состоящие из вложенных объектов). Для декомпозиции агрегатов нужен ещё один уровень абстракции. Назовём его Data Abstraction layer(DAL). Но о нём позже.

О реализации маппера, 2 варианта:

• Dependency Injection, инициатива создания объекта исходит от маппера. При создании объекта передаём ссылку на его маппер.

• Изначальное наделение объектов информацией о их маппере.

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

Опять же удобно сделать MappersManager, который будет конструировать мапперов.

IdentityMap для объектов:
Неплохо бы кешировать объекты, чтобы при повторном обращении к мапперу получать данные из кеша, 2 варианта:

• декоратор к мапперу

• отдельный компонент, обращение к которому маппер делает самостоятельно

Мне нравится второй, т.к. в маппере могут быть самостоятельные обращения к IdentityMap.

Lazy Load конструирование данных:
При выборке большого количества объектов, маппер возвращает итератор над коллекцией, элементы которой будут созданы только в момент фактического доступа (foreach), 2 варианта:

• либо отключаем IdentityMap для этой коллекции

• либо используем инвалидацию хранилища в IdentityMap(сброс кеша).

Инвалидация IdentityMap:
Для этого все создаваемые маппером объекты нужно обернуть в проксирующие дектораторы. Которые декорируют метод объекта getId(), без фактического обращения к объекту. Иногда это выручает, т.к. не всем нужно кроме Id элемента что-то ещё.
Этот проксирующий декоратор позволит создать объект, в случае, если хранилище IdentityMap было инвалидировано.

Зависимые загрузки. Проблема 1+n запросов.
$posts = $user->posts() и затем foreach $posts->comments() фактически вызовет N запросов(для каждого поста по запросу), решается уведомлением зависимого маппера о вероятном использовании некоторых объектов. Например CommentMapper::notifyUsage($comment_id) или MapersManager::getMapper(‘comment’)->notifyUsage($comment_id);
Но для этого нужно отказаться от итератора над коллекцией возвращаемых значений для постов.

Связи. Самое сложное, 2 решения:

• Анемичная модель: PostService::addComment($post, $comment). В этом случае PostService должен выполнить операцию сам(изменить фактические данные). Для этого он должен знать о реальной структуре хранимых данных. И обращаться ему придётся к Data Abstration Layer, на уровень ниже.

• Богатая модель: $post->addComment($comment); В этом случае, вероятно, вызов должен быть делегирован обоим мапперам, чтобы каждый выполнил свою часть операции. Хранение связей в MongoDB отличается от реляционной модели. Возможно связь должны хранить оба элемента(тип значения «список» в MongoDB).

Скрипты(отчёты, регламентные процедуры, и.т.д.):

Скрипты в доменной модели, всегда веселуха. Напрямую обращаться к базе нельзя, всё через уровень доменной модели. Медленно.

Резюме:

Это только первый слой, без Data Abstration Layer. Выглядит уже сложно. Возникает ощущение программирования ради программирования.

Как возможная альтернатива: Анемичная модель и отказ от объектов пользу массивов. Интеграция приложения на уровне базы данных, когда всё приложение пронизано знанием о способе хранения и структуре возвращаемых данных.

Как показывает опыт анемичная модель доминирует в вебе. Суппорт анемичной модели так же более лёгкое занятие.

Есть ли IDE, правильно подавтокомплитящие $b->get()-> для следующего кода?:

<?php
  class a {
    public function returnObject() {
      return new object_a();
    }
 
    public function get() {
      return $this->returnObject();
    }
  }
 
  class b extends a {
    public function returnObject() {
      return new object_b();
    }
  }
 
 
  class object_a {
    public $a;
    public $aa;
  }
 
  class object_b {
    public $b;
    public $bb;
  }
 
  $a = new a();
  $a->get()->a;
 
  $b = new b();
  $b->get()->

На этот год было запланировано путешествие на Пхукет.

Тайланд нас встретил лёгким дождём, влажным тёплым воздухом.

Хронология:
26.11.2012

• Вылет из Новосибирска

27.11.2012

• Прилёт на Пхукет
• Заселение в The Natural Resort.
• Окрестности.

28.11.2012

• Пляж Патонг

29.11.2012

• Пляж Патонг

30.11.2012

• Аквапарк

1.12.2012

• Заповедник КаоСок + высокогорное озеро Чао Лан (день 1)

2.12.2012

• Заповедник КаоСок + высокогорное озеро Чао Лан (день 2)

3.12.2012

• Остров Пхи-Пхи

4.12.2012

• пляж Патонг

5.12.2012

• Остров Рача

6.12.2012

• Пляж Патонг

7.12.2012

• Остров Джеймс-Бонда

8.12.2012

• Пляж Патонг

9.12.2012

• Шопинг

10.12.2012

• Отдых

11.12.2012

• Вылет в Новосибирск

Затянул второй курс по MongoDB для DBA.
Теперь могу сетапить и рулить шарды и реплики, строить индексы и прочие ништячки.

Завершил на пятёрку =)
2 ошибки в экзамене:

A bunch of RDBMS guys walk into a NoSQL bar. But they don’t stay long. They could not find a table.