Комментарии 10
Отличный перевод не менее отличной статьи. Так держать!
Просто и понятно!
Огромное спасибо что ещё раз напомнили о главном!
Огромное спасибо что ещё раз напомнили о главном!
C трудом представляю себе независимое проектирование в общем случае.
-Заказчик формулирует user story
-Аналитик придумывает, как это реализовать
-Заказчику демонстрируется прототип или его описание. Обычно описание идет исключительно в терминах GUI — будет вот такая форма, там вот такая кнопка и т.д.
-После согласования слой бизнес-логики дорабатывается чтобы обеспечить потребности GUI ( или интерфейса другого типа )
-Доработка слоя бизнес логики часто вызывает доработку БД
Т.е. проектирование обычно идет сверху вниз GUI => Логика => БД, согласно порядку появления требований к системе.
Как можно изолированно проектировать логику или БД, от чего отталкиваться, неясно.
-Заказчик формулирует user story
-Аналитик придумывает, как это реализовать
-Заказчику демонстрируется прототип или его описание. Обычно описание идет исключительно в терминах GUI — будет вот такая форма, там вот такая кнопка и т.д.
-После согласования слой бизнес-логики дорабатывается чтобы обеспечить потребности GUI ( или интерфейса другого типа )
-Доработка слоя бизнес логики часто вызывает доработку БД
Т.е. проектирование обычно идет сверху вниз GUI => Логика => БД, согласно порядку появления требований к системе.
Как можно изолированно проектировать логику или БД, от чего отталкиваться, неясно.
Прям пентакль получился О_о
Создается ощущение, что «изолированное проектирование» — это, типа, сильвербуллит, лишенный недостатков. Хотя так не бывает. Но дело даже не в этом.
Дело в том, что в этом сценарии слой «бизнес-логики» перестал быть бизнес-логикой и стал датамаппером. Что нифига не одно и то же.
Дело в том, что в этом сценарии слой «бизнес-логики» перестал быть бизнес-логикой и стал датамаппером. Что нифига не одно и то же.
Собственно, продолжение статьи именно это и показывает. Посмотрите на функции разработчика бизнес-слоя:
" 1. Создание и внедрение внешних интерфейсов, необходимых слою представления, с помощью веб-сервисов или других средств удаленного взаимодействия.
2. Определение внешних интерфейсов, используемых слоем представления.
3. Формирование требований к представлению данных и хранимым процедурам слоя хранения данных.
4. Реализация всех преобразований данных между виртуальным и физическим слоем.
5. Создание первичных регрессивных тестов для построения и тестирования слоя бизнес-логики."
И в картинке написано — implement transform.
Все это лишний раз нам говорит о том, что никакой «логики» в этом бизнес-слое нет, а есть там исключительно дата-маппинг.
А стоило бы там появиться логике, как сразу бы стало понятно, что проектирование должно идти совсем с другой стороны (здесь передаю пламенный привет DDD).
PS Expandability — это не масштабируемость, не вводите людей в заблуждение. Это расширяемость.
" 1. Создание и внедрение внешних интерфейсов, необходимых слою представления, с помощью веб-сервисов или других средств удаленного взаимодействия.
2. Определение внешних интерфейсов, используемых слоем представления.
3. Формирование требований к представлению данных и хранимым процедурам слоя хранения данных.
4. Реализация всех преобразований данных между виртуальным и физическим слоем.
5. Создание первичных регрессивных тестов для построения и тестирования слоя бизнес-логики."
И в картинке написано — implement transform.
Все это лишний раз нам говорит о том, что никакой «логики» в этом бизнес-слое нет, а есть там исключительно дата-маппинг.
А стоило бы там появиться логике, как сразу бы стало понятно, что проектирование должно идти совсем с другой стороны (здесь передаю пламенный привет DDD).
PS Expandability — это не масштабируемость, не вводите людей в заблуждение. Это расширяемость.
К сожалению, идти совсем от модели (ну или от тестов для модели, что в общем-то принципиально одно и тоже) нельзя. Нету никаких xDD в чистом виде и сказать «с чего начинается разработка» нельзя. Но можно обобщить и сказать, что разработка начинается с наших знаниях о пректе, т.е. с идей, которые в дальнейшем транслируются в код. А насчет data mapper согласен, как-то слишком все примитивно.
«сказать «с чего начинается разработка» нельзя»
Ну почему же. Для каждого конкретного проекта обычно можно.
Впрочем, чаще всего разработка начинается с требований. Дальше вопрос в том, как они сформулированы, и во что они воплощаются. Некоторые требования сначала определяют модель данных, некоторые — UI, некоторые — бизнес-сущности. Все зависит от того, какова сложность, размер и направленность проекта.
Ну почему же. Для каждого конкретного проекта обычно можно.
Впрочем, чаще всего разработка начинается с требований. Дальше вопрос в том, как они сформулированы, и во что они воплощаются. Некоторые требования сначала определяют модель данных, некоторые — UI, некоторые — бизнес-сущности. Все зависит от того, какова сложность, размер и направленность проекта.
А, я понял откуда эти хвосты все растут. Статья 2005-го года (редкостный свежак, да). Я-то думаю, откуда там такие смешные распределения в «modern systems».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Взаимодействие звеньев и их изоляция. Часть 1