Объектно-ориентированная охота на мамонта (записки делопроизводителя)

[lair]

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

Вы правда считаете, что бизнес-аналитик описал бы процесс так?

У делопроизводителя лучше. Почему?

Потому что вы играете на его стороне.

Потому что первый строит модель на основе объектов, а второй на основе процессов.
Потому что первый мыслит существительными, а второй глаголами.

Это какие-то выдуманные вами разделения. Хороший аналитик мыслит бизнес-процессами, смоделированными в нескольких представлениях, из которых одно — сущностное, другое — по действиям, третье — по сценариям, четвертое — по акторам и так далее.

Недавно один профессионал в части построения систем с полной уверенностью заявил мне, что бухгалтерский счет не является документом. [...] Насколько же глубоко в мозги должно засесть процессо-ориентированное мышление, чтобы основание для платежа с номером, датой, подписями не считать документом, а считать одной из отчетных форм процесса.

Добро пожаловать в мир тщательно выкопанных ям-ловушек (их изобрели вместе с охотой на мамонтов). В оригинальной фразе было написано «счета и проводки — не документы». А знаете, почему? Потому что вы под счетом понимаете документ на оплату предоставленных услуг/товаров, а фраза — счет в банке или другой кредитной организации. Такой, знаете, с которого деньги списывают, зачисляют и так далее.

Бизнес-аналитик: Заявка – это процесс.

Собственно, наглядная демонстрация всей вашей статьи: вы выдумали себе некоего идеально плохого бизнес-аналитика и идеально хорошего делопроизводителя, и сравниваете их.

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

1. Заявка — это сущность, инициирующая бизнес-процесс.

ДП: Заявка может иметь документ-основание: например входящее письмо, расписанное на исполнителя с резолюцией «Прошу извести жука и дать ответ заявителю». Это значит, что ответ заявителю будет на нее ссылаться.
Б-А: ну и что? Вот такой у нас процесс.

2. Сущность заявка действительно может быть связана с сущностью документ-основание, но это зависит от процесса (и я не знаю ни одного процесса управления ошибками, где был бы выделенный документ-основание). Скорее всего, это разделение избыточно, и достаточно говорить о заявке, у которой может быть сложный атрибутивный состав.

ты не понимаешь. Входящий сканируют и присоединяют, статус процесса меняется, начальник должен наложить резолюцию…

Этого в управлении ошибками не бывает, поэтому пропускаем весь кусок.

Заявку рассматривает руководитель проекта и расписывает на исполнителей.

Прекрасно.

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

В управлении ошибок это формулируется совершенно не так.

3.
Вариант (1), простой: заявке напрямую назначается ответственный, он же является исполнителем.
Вариант (2), сложный: заявке напрямую назначается ответственный, создаются дочерние задачи, каждая из которых назначается на исполнителя.

Требований на неизменяемость в управлении ошибками обычно нет, а вот требования на историчность — есть.

Исполнитель начинает работу по изведению жука.
Бизнес-аналитик: Работа – это процесс. Любого спроси.
Пользователь: Ты прав.
Делопроизводитель: в базу записывается не работа, а отчет о работе (начало, содержание, процент выполнения) – а это документ. [...]
Б-А: Какой-такой доко-бд-монго-дб? База должна быть реляционной и три раза нормализованной. Посмотри вокруг: большинство систем в мире создано нами.

Тут, надо заметить, и делопроизводитель, и аналитик совершили непозволительную ошибку — начали навязывать реализацию до завершения анализа, хотя это не их компетенция. Но не важно.

4. Заявка (в формализованном процессе — задача по заявке) перешла в статус «в работе» и позже — «выполнена».

Все, большая часть анализа по вашему процессу завершена. Описываем сущности, сценарии использования — получаем требования на систему.

И, заметим, никакой — вообще никакой — объектно-ориентированности (ни с какой стороны). Потому что ООП — это парадигма проектирования, а не анализа.

[Uint32]

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

В чем я его полностью поддержу. Думаю, это терменологическая путаница. Бухгалтерский счет (синтетический, аналитический) документом не является. А вот счет, выписываемый на оплату — безусловно документ, как документом может быть и выписка по счету.

[lair]

Модель мира (неважно, большого или малого) может быть реализована только в документо-ориентированной базе данных.

Что-то я по первому чтению пропустил этот пункт.

Я надеюсь, вы можете обосновать это — без сомнения, смелое — утверждение? Я же правильно понимаю, что вы имеете в виду, что любая модель, для любых целей может быть реализована только в документо-ориентированной БД? Или, если вы имели в виду что-то другое, то что именно?

[aon24]

Мир состоит из коллекций объектов, а не из прямоугольных таблиц.
Почему, я не знаю.
Свойства объекта удобнее хранить как документ, а не как строчку в таблице.
Если бы замечательный артефакт «1С» имел документо-ориентированную основу,
доработка 1С не была бы самой востребованной работой для программиста в России.
Это мое скромное мнение.

[lair]

Мир состоит из коллекций объектов, а не из прямоугольных таблиц.

Ну вообще — нет, не состоит. Уже термин «коллекция» — это абстракция, которой в мире нет.

Свойства объекта удобнее хранить как документ, а не как строчку в таблице.

Удобнее для чего?

Вы правда искренне не понимаете, что модель определяется задачей, и для одной задачи подходит одна модель, а для другой — другая?

[aon24]

модель определяется задачей

Увы, это заблуждение.
Модель определяется тем, кто ее строит, его пониманием задачи.

для одной задачи подходит одна модель, а для другой — другая

об этом и речь. О том, что документо-ориентированные задачи загоняют в реляционные таблицы.

[lair]

модель определяется задачей
Увы, это заблуждение.
Модель определяется тем, кто ее строит, его пониманием задачи.

Это, к сожалению, демагогия. Модель определяется именно задачей, понимание того, кто ее строит — не более чем посредник.

О том, что документо-ориентированные задачи загоняют в реляционные таблицы.

Вы выше говорили, что любая модель для любой задачи может быть реализована только в документо-ориентированной БД. Нет, я неправильно вас понял?