Автор Тема: Размышления на тему логики предметной области (бизнес-  (Прочитано 20081 раз)

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
В связи с тем, что часто приходится иметь дело с бизнес-логикой, хочу поинтересоваться тем как вы строите  архитектуру программы для того, чтобы было просто приспосабливать программу под частоизменяющиеся требования бизнеса.

В проектах работаю с парадигмой MVC. Проблема состоит в том, что, к сожалению, бизнес-логика размазана по всем трём узлам: она присутствует как в моделях и контроллерах, так и в конечном отображении.
Малейшие изменения в определении бизнес-сущности влекут за собой изменения в трёх узлах:
  • в моделях - логика запросов к БД (есть небольшая абстрактная прослойка над SQL) с зависимостями между моделями
  • в контроллерах - логика обработки входных параметров, подготовка требуемого формата данных и формирование данных
  • в отображении - логика отображения объектов

Что нужно сделать, чтобы сократить количество изменений и свести их к минимуму?

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Что нужно сделать, чтобы сократить количество изменений и свести их к минимуму?
Это единственный критерий оптимизации? Например, тебя устроит если правки в коде будут самыми минимальными, но при этом всё работать станет в двадцать раз медленнее?

Я, кстати, на работе оптимизирую как раз по критерию производительности. То есть правка в коде может быть достаточно большой (например, шесть недель), главное чтобы потом программа работала быстро.

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
Например, тебя устроит если правки в коде будут самыми минимальными, но при этом всё работать станет в двадцать раз медленнее?
Это похоже на риторический вопрос. Ну, конечно, не устроит. ???
Интересует, есть ли какой-то систематический подход к решению данной задачи. Не уж то всё так тривиально?

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

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

alexus

  • Гость
Что нужно сделать, чтобы сократить количество изменений и свести их к минимуму?
Как правило, изменения связаны с тем, что меняются представления пользователей о том, что должна делать программа. В свою очередь, изменение представлений связано с тем, что у руководителей меняются
  • условия/правила работы (изменения во внешней среде);
  • объекты (или представления об объектах) управления (изменения внутри);
  • методы управления (или представления о методах и их применимости), включая методы получения/обработки/анализа/представления данных/показателей деятельности;
С первым видом изменений бороться невозможно, если, конечно нет возможности лоббировать свои интересы в головной компании или... гос. органах (министерствах, ведомствах, Гос. Думе и пр.). Но надо отметить, что изменения во внешней среде происходят, как правило, не слишком часто.
Со вторым видом изменений бороться нельзя, поскольку такая борьба исключит развитие предприятия. Но... этих изменений можно избежать почти полностью, если программное обеспечение построено на качественных моделях, отражающих семантику каждого объекта управления (исходя из тезиса, что семантика меняться не может).
Третьего вида изменений можно избежать, если программное обеспечение представляет собой набор инструментов для пользователей, а не средства решения конкретных задач. То есть, программное обеспечение не берёт на себя функции специалистов предприятия, но даёт им набор средств для решения их задач.

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

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
1. Фирма имеет малый штат. Условно назовём стартапом. Работа с заказчиком происходит практически полностью через менеджера. Менеджер имеет лишь базовые представления о разработке. Большей частью не более чем знание что такое HTML. Менеджер своими словами описывает функциональность В ОБЩИХ СЛОВАХ, тыча пальцем в экран. Гораздо реже показывает снимки экрана или эскизы. Функциональность меняется постоянно, буквально изо дня в день (по очередному изъявлению желания заказчика или же менеджеру, которого заказчик убедил в важности некоторых прибамбасов). Поэтому спецификаций НЕТ. Техническую документацию я веду сам для себя. Другим это неинтересно и не нужно. Нет единого стиля программирования. Каждый пишет как ему угодно. Потом довольно тяжело разбирать чужой код.

2. Код пишется на Ruby на фреймворке Ruby on Rails.
Что касается View, то это длинная история и её нужно рассказывать частями.
Отражаемый на экране текст в большинстве случаев определяет программист (тексты оповещений, ошибок). Английский является базовым языком интерфейса, но он не является родным для программистов. На основе английского производится перевод с помощью схожего с gettext способа (inline).
Например:
  "Dear #{user.name}, you have to select at least one option.".t
Такие строки встречаются и в коде и в вёрстке - всюду. Часто программист исправляет орфографические и синтаксические ошибки как свои, так и чужие. И, при этом, вносит другие. Любое исправление переводимого текста требует обновление базы данных перевода. А поскольку эти изменения часты, то перевод сплошь и рядом отсутствует. Хоть переводом программист не занимается - и то хорошо.

HTML View (embedded Ruby):
<% if selected.size > 0 %>
<div><%= sprintf("%d of %d items selected".t, x, y) %></div>
<% else %>
<div class="error_class1"><%= "No selected items".t %></div>
<% end %>

View helper (Ruby):
if @want_pizza and @user.has_enough_money()
  render_block(pizza)
else
  render_block(start_again)
end

JavaScript:
function save_sub_phones(field_to_update)
{
  var fields = $$(".phone_field")
  var elem;
  var phones=[];
  phones = fields.map(function(field) {
    return field.id.split("_")[1]+"="+field.value;
  } );
  $(field_to_update).value = phones.join(";");
  Element.hide("phone_orders");
}

Пример я привёл с головы, для общего представления. Эти конструкции типичны в нашем коде.

Здесь видно, что несмотря на то, что используется парадигма MVC, код очень быстро засирается сложными конструкциями, состоящими из смеси Ruby/HTML/JavaScript/Ruby Javascript (RJS-Ajax). Вся логика лежит на технологиях нескольких языков и технологий в разных местах.

3. Модели и контроллеры оставлю на следующий раз, ибо всего сразу не переварить.

4. Хотелось бы, чтоб текстами и вёрстками HTML занимались отдельные редакторы, графики или просто компетентные люди. К сожалению, у меня нет влияния на наше руководство, поэтому нет смысла ждать от них чуда.  Поэтому нужно придумать способ отделения данных, вёрстки от кода. Желательно, чтобы основной код был сосредоточен в одном месте и мог быть с лёгкостью изменён, повлияв на генерацию остального кода/шаблонов.
Я постоянно нахожусь в процессе поиска приемлемого решения данной проблемы с тем, чтобы его приняли и другие разработчики. То есть оно должно помочь нам снизить трудозатраты при небольших усилиях.

alexus

  • Гость
1. Фирма имеет малый штат. Условно назовём стартапом. Работа с заказчиком происходит практически полностью через менеджера.
Логично. Если с заказчиками будут общаться разработчики... сегодня один, завтра другой... то заказчик сбежит.

Менеджер имеет лишь базовые представления о разработке. Большей частью не более чем знание что такое HTML. Менеджер своими словами описывает функциональность В ОБЩИХ СЛОВАХ, тыча пальцем в экран. Гораздо реже показывает снимки экрана или эскизы.
Должно быть описание продуктов, их функциональных возможностей, дизайна, преимуществ и пр. Менеджеру будет значительно проще работать с заказчиками, отвечать на их вопросы, готовить презентации... Помимо этого неплохо бы собирать отзывы и пожелания от заказчиков, которые уже приобрели продукты фирмы. Эти пожелания должны передаваться руководству фирмы, чтобы планировались изменения с учётом мнения заказчиков.

Функциональность меняется постоянно, буквально изо дня в день (по очередному изъявлению желания заказчика или же менеджеру, которого заказчик убедил в важности некоторых прибамбасов). Поэтому спецификаций НЕТ. Техническую документацию я веду сам для себя. Другим это неинтересно и не нужно. Нет единого стиля программирования. Каждый пишет как ему угодно. Потом довольно тяжело разбирать чужой код.
Довольно типичная ситуация для фирм, которые провели несколько удачных продаж. Если продажи упадут, фирма рассыпется, если вырастут, то... тоже рассыпется... или поумнеет.
Если Вы опишите функциональность продуктов, то можно подумать над тем, почему она меняется так часто... Причина, в принципе понятна, она связана с недостаточной проработанностью исходной модели. Но детали обсудить пока невозможно.

2. Код пишется на Ruby на фреймворке Ruby on Rails.
Что касается View, то это длинная история и её нужно рассказывать частями.
Отражаемый на экране текст в большинстве случаев определяет программист (тексты оповещений, ошибок). Английский является базовым языком интерфейса, но он не является родным для программистов. На основе английского производится перевод с помощью схожего с gettext способа (inline).
Например:
  "Dear #{user.name}, you have to select at least one option.".t
Такие строки встречаются и в коде и в вёрстке - всюду. Часто программист исправляет орфографические и синтаксические ошибки как свои, так и чужие. И, при этом, вносит другие. Любое исправление переводимого текста требует обновление базы данных перевода. А поскольку эти изменения часты, то перевод сплошь и рядом отсутствует. Хоть переводом программист не занимается - и то хорошо.
Строки с текстом можно вынести в отдельные файлы, каждому сообщению присвоить идентификатор (константу), который остаётся стабильным независимо от языка общения. Соответственно, переводчики должны поддерживать согласованность всех разноязычных файлов, а программисты пополняют изменяют только файл на своём (русском, например) языке. При этом у каждого разработчика может быть свой вариант файла и свой диапазон идентификаторов.

HTML View (embedded Ruby):
Пример кода я не комментирую.

Пример я привёл с головы, для общего представления. Эти конструкции типичны в нашем коде.

Здесь видно, что несмотря на то, что используется парадигма MVC, код очень быстро засирается сложными конструкциями, состоящими из смеси Ruby/HTML/JavaScript/Ruby Javascript (RJS-Ajax). Вся логика лежит на технологиях нескольких языков и технологий в разных местах.
Для того, чтобы аккуратно разнести это "вавилонское столпотворение", необходимо разобраться с моделью программного обеспечения, эту модель и разделить по интерфейсам в зависимости от возможностей того или иного средства разработки...

4. Хотелось бы, чтоб текстами и вёрстками HTML занимались отдельные редакторы, графики или просто компетентные люди.
Да, это правильное желание. Если оно неосуществимо, то эти функции можно разделить между разработчиками. Так чтобы вопросы дизайна/вёрстки (внешнего представления) решал кто-то один, графику разрабатывал кто-то другой, тексты сочинял третий и т.д. Такое разделение труда иногда кажется избыточным, но ростом объёма работы, оно позволит работать быстрее, а само программное обеспечение выглядит более однородно и эргономично. А главное... каждый специалист подумает над тем, чтобы облегчить свою участь... и, возможно, предложит простые инструменты, способные позволить решать текущие задачи быстрее и в одном стиле. Но если объёмы работ небольшие, то затраты на разработку инструментов не окупятся.

К сожалению, у меня нет влияния на наше руководство, поэтому нет смысла ждать от них чуда.  Поэтому нужно придумать способ отделения данных, вёрстки от кода. Желательно, чтобы основной код был сосредоточен в одном месте и мог быть с лёгкостью изменён, повлияв на генерацию остального кода/шаблонов.
Я постоянно нахожусь в процессе поиска приемлемого решения данной проблемы с тем, чтобы его приняли и другие разработчики. То есть оно должно помочь нам снизить трудозатраты при небольших усилиях.
Вы думаете в правильном направлении, но начинать надо с модели...

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
С моделями дело обстоит сложнее. Когда я устроился на фирме, к тому времени монстры-модули, состоящие из десятков атрибутов с многочисленными связями-спагетти уже существовали. Тогда у меня вообще ноль опыта было. При этом, я быстро понял, что их можно было бы существенно сократить без ущерба функциональности.
Но так уж повелось и поменять подход, повыбрасывав ненужное, можно только если все вместе на это будут согласны. Потому что в рефакторинге этого проекта я смысла не вижу - его нужно писать с нуля, учтя прежние неудачные подходы. А при построении этого проекта не было четкого понимание предметной области, так как решили осваивать новый рынок. Все это было сделано без консультаций со специалистами.
Так или иначе, менять модели уже нельзя. Можно лишь проектировать новые с функциональностью старых, а потом от последних избавляться. А на это время не уделяется.

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
При всем этом нужно найти способ трансляции требований бизнеса в инструкции по генерации кода работы с моделями и отображением. Если с конечным кодом более-менее ясно, то вот с формализацией бизнеса все гораздо сложнее. А без формализации предметной области автоматизировать процесс никак не получится.

alexus

  • Гость
С моделями дело обстоит сложнее. Когда я устроился на фирме, к тому времени монстры-модули, состоящие из десятков атрибутов с многочисленными связями-спагетти уже существовали. Тогда у меня вообще ноль опыта было. При этом, я быстро понял, что их можно было бы существенно сократить без ущерба функциональности.
Но так уж повелось и поменять подход, повыбрасывав ненужное, можно только если все вместе на это будут согласны. Потому что в рефакторинге этого проекта я смысла не вижу - его нужно писать с нуля, учтя прежние неудачные подходы. А при построении этого проекта не было четкого понимание предметной области, так как решили осваивать новый рынок. Все это было сделано без консультаций со специалистами.
Так или иначе, менять модели уже нельзя. Можно лишь проектировать новые с функциональностью старых, а потом от последних избавляться. А на это время не уделяется.
Мы с Вами понимаем нечто разное, когда говорим о моделях. Вопрос не в том... менять модели или не менять... Вопрос в том, чтобы найти (умозрительно построить) полную и непротиворечивую (формальную) модель деятельности (предприятия или отдела)... деятельности, попадающей под автоматизацию. Это не модель базы данных, не модель программного обеспечения, не та модель, которая существует в головах руководителей... или ваших заказчиков. Все перечисленные модели - это частные проекции, а нужна единая/целая/общая модель... то есть, семантическая модель, отражающая смысл/суть этой деятельности. И тогда, имея такую модель, станет понятно, что надо менять и в программном обеспечении, и в управлении предприятием (то есть, в голове руководителей), и в плане выстраивания отношений с заказчиками... и любые другие частности. При этом не надо впадать в крайности, считая что такая модель либо невозможна, либо очень сложна, либо излишне абстрактна/бесполезна (a'la "сферический конь в вакууме").

adva

  • Sr. Member
  • ****
  • Сообщений: 385
    • Просмотр профиля
... а нужна единая/целая/общая модель... то есть, семантическая модель, отражающая смысл/суть этой деятельности. ...
Хотел уточнить, Вы на оберонкоре для предприятия ТАКУЮ модель представляли? Или что то другое? (тема называлась содержание деятельности, кажется). Это я к тому, чтобы еще раз перечитать, т.к. сразу только мельком просмотрел из-за нехватки времени, но тема тоже интересует.

alexus

  • Гость
... а нужна единая/целая/общая модель... то есть, семантическая модель, отражающая смысл/суть этой деятельности. ...
Хотел уточнить, Вы на оберонкоре для предприятия ТАКУЮ модель представляли? Или что то другое? (тема называлась содержание деятельности, кажется). Это я к тому, чтобы еще раз перечитать, т.к. сразу только мельком просмотрел из-за нехватки времени, но тема тоже интересует.
Любая деятельность формализуется (для любой деятельности можно построить формальную модель). Да, на оберонкоре я выкладывал модели основных видов предприятий, но развития тема не получила, и в существо подсистем мы не погружались. Как, собственно, не рассматривался и макроэкономический уровень. А здесь скорее всего потребуется модель одной из подсистем. Хотя автору темы виднее...

DIzer

  • Гость


Любая деятельность формализуется (для любой деятельности можно построить формальную модель). Да, на оберонкоре я выкладывал модели основных видов предприятий, но развития тема не получила, и в существо подсистем мы не погружались. Как, собственно, не рассматривался и макроэкономический уровень. А здесь скорее всего потребуется модель одной из подсистем. Хотя автору темы виднее...
И не  получит, и  дело  не в оберон коре - а в том , что она требует определенного уровня развития восприятия, который свойственен скорее администраторам чем исполнителям...

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
С моделями дело обстоит сложнее. Когда я устроился на фирме, к тому времени монстры-модули, состоящие из десятков атрибутов с многочисленными связями-спагетти уже существовали. Тогда у меня вообще ноль опыта было. При этом, я быстро понял, что их можно было бы существенно сократить без ущерба функциональности.
Но так уж повелось и поменять подход, повыбрасывав ненужное, можно только если все вместе на это будут согласны. Потому что в рефакторинге этого проекта я смысла не вижу - его нужно писать с нуля, учтя прежние неудачные подходы. А при построении этого проекта не было четкого понимание предметной области, так как решили осваивать новый рынок. Все это было сделано без консультаций со специалистами.
Так или иначе, менять модели уже нельзя. Можно лишь проектировать новые с функциональностью старых, а потом от последних избавляться. А на это время не уделяется.
Мы с Вами понимаем нечто разное, когда говорим о моделях. Вопрос не в том... менять модели или не менять... Вопрос в том, чтобы найти (умозрительно построить) полную и непротиворечивую (формальную) модель деятельности (предприятия или отдела)... деятельности, попадающей под автоматизацию. Это не модель базы данных, не модель программного обеспечения, не та модель, которая существует в головах руководителей... или ваших заказчиков. Все перечисленные модели - это частные проекции, а нужна единая/целая/общая модель... то есть, семантическая модель, отражающая смысл/суть этой деятельности. И тогда, имея такую модель, станет понятно, что надо менять и в программном обеспечении, и в управлении предприятием (то есть, в голове руководителей), и в плане выстраивания отношений с заказчиками... и любые другие частности. При этом не надо впадать в крайности, считая что такая модель либо невозможна, либо очень сложна, либо излишне абстрактна/бесполезна (a'la "сферический конь в вакууме").
Кажется теперь я стал понимать о чём речь. Исходя из сказанного, прихожу к выводу, что это уровень выше программно-исполнительного и он пересекается больше с деятельностью руководства, чем с программистов. Он неподвластен мне - вряд ли я смогу получить от кого-либо непротиворечивую модель деятельности нашего проекта. Я понимаю, что нужно начинать с уровня выше, но руководство само нечётко понимает происходящие процессы и уж, тем более, не в состоянии формализовать его. Являюсь самым младшим звеном в этой цепи. Должности "архитектора ПО" у нас нет.
Построение семантической модели деятельности мне кажется довольно интересной темой, однако я задавал вопрос с намерением облегчить участь деятельности программистов (моей в частности).

DIzer

  • Гость
Кажется теперь я стал понимать о чём речь. Исходя из сказанного, прихожу к выводу, что это уровень выше программно-исполнительного и он пересекается больше с деятельностью руководства, чем с программистов. Он неподвластен мне - вряд ли я смогу получить от кого-либо непротиворечивую модель деятельности нашего проекта. Я понимаю, что нужно начинать с уровня выше, но руководство само нечётко понимает происходящие процессы и уж, тем более, не в состоянии формализовать его. Являюсь самым младшим звеном в этой цепи. Должности "архитектора ПО" у нас нет.
Построение семантической модели деятельности мне кажется довольно интересной темой, однако я задавал вопрос с намерением облегчить участь деятельности программистов (моей в частности).
Да вы поняли правильно -конкретные архитектурные решения , всего лишь следствия вашего ПОНИМАНИЯ сущности проблемы... И все остальное верно.... А в конце вы ответили на свой вопрос - хотите облегчить участь свою -а не программистов , которых вполне вероятно что устраивает текущая ситуация (либо по другой причине) -переходите на другой  уровень. Весь вопрос в степени личной мотивации - мне видится, что все остальное у вас УЖЕ есть...
)

alexus

  • Гость
Любая деятельность формализуется (для любой деятельности можно построить формальную модель). Да, на оберонкоре я выкладывал модели основных видов предприятий, но развития тема не получила, и в существо подсистем мы не погружались. Как, собственно, не рассматривался и макроэкономический уровень. А здесь скорее всего потребуется модель одной из подсистем. Хотя автору темы виднее...
И не  получит, и  дело  не в оберон коре - а в том , что она требует определенного уровня развития восприятия, который свойственен скорее администраторам чем исполнителям...
Не знаю... не знаю... Модели очень простые, я читал лекции студентам 3-4 курса, никаких трудностей с пониманием у них не возникало. Наоборот, они жалели, что узнали о системном подходе к экономическим моделям слишком поздно, когда, собственно, экономику им уже отчитали. Вместо заучивания приходит понимание основополагающих процессов.