Шаблон дизайна или запах кода, денормализованные данные в результате функциональной декомпозиции

Question

Я большой поклонник http://highscalability.com/, и я искал в своей текущей разработке, чтобы разложить мое приложение по функциональным границам в качестве пути к возможности масштабирования на стороне сервера, особенно на уровне базы данных. Это включает в себя реализацию различных функциональных компонентов приложения (у нас есть несколько отдельных модулей, которые клиенты могут использовать) в качестве своего собственного независимого приложения на сервере, клиент, который обращается к серверу, знает о различных службах, с которыми ему нужно связаться для получения различных данных, так унифицированное представление представлено пользователям. Проблема возникает, когда существуют ссылки между данными в разных компонентах, то есть один компонент содержит все пользовательские данные, а другой должен ссылаться на пользователя как на владельца некоторого фрагмента данных. В настоящее время я делаю это, храня информацию о первичном ключе для каждой стороны ссылки (как если бы они все жили в одной базе данных), но эта таблица ссылок должна существовать в обоих компонентах, чтобы можно было выполнять поиск в В любом направлении, то есть «получить вещи, принадлежащие конкретному пользователю» и «получить владельцев этой конкретной вещи», каждый из них будет использовать разные компоненты. Альтернативой этому может быть сохранение данных ссылки только в одном из компонентов, но тогда обратный поиск потребует 2 вызова вместо одного.

У меня такой вопрос, является ли дублирование этих таблиц ссылок каким-то запахом кода, которого я должен избегать, или это именно то, как идут дела, когда вы разбиваете свое приложение по функциональным линиям, как это?

Answer 1

Функциональная декомпозиция - плохая стратегия проектирования.

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

Функциональная декомпозиция предназначена для анализа требований. Это не для дизайна.

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

Answer 2

Я думаю, что это зависит - разве SOA не означает функциональную декомпозицию ??

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

Если вы пытаетесь масштабировать кухню до завода по производству пищевых продуктов, то может иметь смысл иметь отдельные чаны для взбивания, перемешивания и смешивания с каким-то трубопроводом (или «шиной»), на который чаны «подписываются» к, но для dometic блендера было бы более целесообразно повторно использовать ту же чашу и иметь переключаемые насадки.