Size: a a a

Архитектура ИТ-решений

2019 August 23

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Andrey Kharintsev
Необходимо решение, чтобы документировать изменения структуры (модели) базы данных. Обычно от аналитика приходит огромный документ Word с таблицей внутри, когда его спрашиваешь что изменилось в документе, описывающем БД - он говорит не знаю, вот моя постановка читай ищи. Расскажите свой опыт.
Сегодня под руку подвернулось, кажется это то что вам надо.
Исходные файлы хранить в Git.
https://www.quickdatabasediagrams.com/
источник
2019 August 25

ТЛ

Тимур Латыпов in Архитектура ИТ-решений
Andrey Kharintsev
Необходимо решение, чтобы документировать изменения структуры (модели) базы данных. Обычно от аналитика приходит огромный документ Word с таблицей внутри, когда его спрашиваешь что изменилось в документе, описывающем БД - он говорит не знаю, вот моя постановка читай ищи. Расскажите свой опыт.
По моему это в т.ч. проблема организационного характера. И если это вам нужно, то стоит поговорить об этом с руководством аналитиков/программистов. В наших документах, есть раздел "Изменения..." где описываются версия документа, дата изменения, внесенные изменения. Этот раздел формируется автоматически либо ведется вручную.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Сколько всего пропустил)

По требованиям, должен аналитик описывать структуру БД или нет.

На практике пришёл к тому, что аналитики и разработчики должны договариваться о гранулярности требований. Для каждого проекта это индивидуально, зависит от "конфигурации" команды.

Больше того, о гранулярности должны договаривать БА и СА. И это итеративный процесс.

Договариваться должны не только о гранулярности требований, но и порождаемых артефактах.

Солюшен фасилитирует этот процесс.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
И в тоже время, когда аналитики описывают структуру БД, они это делают скорее "для себя". Потому что хорошие разработчики всё равно сделают по-своему.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
@saabeilin по бест практис
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
@saabeilin отправил презу в личку ) сорри
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Что касается инструментария, аналитики могут описывать «свою версию» структуры БД на чём угодно. Они это делают «для себя» или чтобы разработчики уловили их мысль.

Реальная же структура действительно в коде, в гите. Это может liquibase, flyway или просто DDL в текстовых (.sql) файлах.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Почему это так. Аналитики никогда не спроектируют базу так, чтобы учитывались все нюансы производительности и отображения на код. Я уже не говорю про CQRS, где у любого сервиса может быть много баз, причём не только реляционных.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Если аналитики (БА и СА) не взаимодействуют между собой и не взаимодействуют с разработчиками, не договариваются между собой, это значит нет нормальной проектной/продуктовой команды. Перекидываться документами посредством формальной процедуры изменений, это не лучший вариант.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Есть исключение. Если используется MDD, то тогда структура базы генерируется с помощью магии соотв. инструментария MDD. Тут действительно всё может быть в руках аналитиков.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Иными словами. БА должны договориться с СА, в каком виде и с какой степенью детализации (гранулярностью) выдавать требования. СА должны договориться о том же с разработчиками. Это никогда не получается сразу, нужно несколько итераций.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Если договориться невозможно и/или процесс строго формализован, то с требованиями всё будет хорошо, но они скорее всего не будут отражать реальной картины. Требования будут жить своей жизнью, а структура базы своей.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Если требования можно оттрассировать на артефакты разработки, и если структура базы это код, то таких проблем быть не должно.
источник

AV

Alexander Vinogradov in Архитектура ИТ-решений
Gennadiy Kruglov
Если требования можно оттрассировать на артефакты разработки, и если структура базы это код, то таких проблем быть не должно.
Вы считаете что не адекватные профессионалы, а именно процесс трассировки даст результат? )
источник

S

Sergey in Архитектура ИТ-решений
если все хорошо, то все хорошо. А если не хорошо, то есть трассировка или нет , а все плохо будет. С MDD так еще хуже :)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Alexander Vinogradov
Вы считаете что не адекватные профессионалы, а именно процесс трассировки даст результат? )
Почему Вы сделали такой вывод?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Sergey
если все хорошо, то все хорошо. А если не хорошо, то есть трассировка или нет , а все плохо будет. С MDD так еще хуже :)
MDD я не рекомендую. Лишь сказал, что MDD даёт иллюзию программирования через модели.
источник

AV

Alexander Vinogradov in Архитектура ИТ-решений
Gennadiy Kruglov
Почему Вы сделали такой вывод?
Согласен, есть манипуляция, просто у вас прозвучало дескать "сделайте трассировку и сразу всегда будете иметь удовлетворенного заказчика
источник

S

Sergey in Архитектура ИТ-решений
в том-то и проблема, что MDD дает иллюзию, а порождает вполне реальные проблемы. Основная из них - привязка к конкретному тулу и война с ним.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Alexander Vinogradov
Согласен, есть манипуляция, просто у вас прозвучало дескать "сделайте трассировку и сразу всегда будете иметь удовлетворенного заказчика
Не вижу прямой связи, если честно. Трассировка позволяет "найти концы" если потребуется.
источник