Комментарии 16
Хорошее описание хорошей архитектуры.
С моментом про слои приложения я несколько не согласен. Вообще со слоями весьма спорная тема. Где-то слои есть, где-то нет. По мне слои в большинстве приложений идут от железа к бизнес логике:
работа с процессором > работа с операционкой > работа с БД > прием, валидация данных > логика доступа > бизнес логика > пользовательский интерфейс.
Самое сложное для большинства компаний на начальных этапах это понять, что разработчика нужно обучить системе, рассказать про структуры данных, основные сущности и тд… и вообще вести документацию по всем сущностям.
80% всех проблем от того, что нет понимания работы системы. Что уже сделано и где. Начинаются задвоения логики и каждая ветка логики начинает расходиться с реальностью.
Давние сорудники считают что все и так понятно, читай код и все поймешь, а новый сотрудник даже если он супер спец, просто не в состоянии догадаться для чего нужна каждая из 1500 таблиц в БД и нюансы работы каждого поля.
И еще момент забыли: кладезь ценных знаний — тестировщик. Тестировщик не просто человек, пытающийся сломать систему или выявить неудобства. Это «друид», который знает всякие нюансы разных фич. И стоило бы чаще принимать у таких людей мастер-классы по работе системы. Если конечно вы не единственный разраб и всю систему сами написали.
С моментом про слои приложения я несколько не согласен. Вообще со слоями весьма спорная тема. Где-то слои есть, где-то нет. По мне слои в большинстве приложений идут от железа к бизнес логике:
работа с процессором > работа с операционкой > работа с БД > прием, валидация данных > логика доступа > бизнес логика > пользовательский интерфейс.
Самое сложное для большинства компаний на начальных этапах это понять, что разработчика нужно обучить системе, рассказать про структуры данных, основные сущности и тд… и вообще вести документацию по всем сущностям.
80% всех проблем от того, что нет понимания работы системы. Что уже сделано и где. Начинаются задвоения логики и каждая ветка логики начинает расходиться с реальностью.
Давние сорудники считают что все и так понятно, читай код и все поймешь, а новый сотрудник даже если он супер спец, просто не в состоянии догадаться для чего нужна каждая из 1500 таблиц в БД и нюансы работы каждого поля.
И еще момент забыли: кладезь ценных знаний — тестировщик. Тестировщик не просто человек, пытающийся сломать систему или выявить неудобства. Это «друид», который знает всякие нюансы разных фич. И стоило бы чаще принимать у таких людей мастер-классы по работе системы. Если конечно вы не единственный разраб и всю систему сами написали.
Также можно добавить, что DDD предполагает ведение документации, которая не отстает от кода. Намного легче вникать в проекты, где подобная документация всё-таки есть
Скорее в DDD сам код и есть документация прежде всего.
Верно. Писать самодокументируемый код — это must have, но какие-то сложные моменты, касающиеся архитектуры, бизнес-логики, неплохо описать и в документации https://yandex.ru/turbo?text=https%3A%2F%2F5minphp.ru%2Fepisode63%2F
Я здесь кратко упоминаю в шаге 1 о тест-кейсах. Конечно их роль огромна, как и роль тестировщика. Изначально в статье были пункты Реализация и Тестирование, а в аналитике было подробное описание того как составлять скрипты, одновременно являющиеся и задачами на разработку по BDD и тест кейсами для приёмки таких задач, но это выросло в 2 отдельных статьи, которые я сейчас параллель пишу. Так что всё впереди)
Есть ощущение, что класс CloudManager нарушает принцип SRP — это видно даже по нарисованной схеме, как будто бы нужно разделить на три разных класса.
В остальном хорошее описание архитектуры, спасибо. Также есть вопрос про слои: в голове разработчика они, допустим, есть, но в чем фактически выражается разделение на слои? Как, взглянув на проект, понять сколько тут слоев, и какой класс к какому слою относится? И где границы слоя.
В остальном хорошее описание архитектуры, спасибо. Также есть вопрос про слои: в голове разработчика они, допустим, есть, но в чем фактически выражается разделение на слои? Как, взглянув на проект, понять сколько тут слоев, и какой класс к какому слою относится? И где границы слоя.
Инструментами статанализа, например, или просто руками нарисовать диаграмму классов и расположить классы так, чтобы зависимости в идеале у каждого класса, на практике у их кластеров, шли только в двух направлениях, вперёд и вбок. Если получилось, то строго слоённая архитектура и слои, обычно, визуально различимы.
Ну а так, часто названия слоёв используется в качестве части полного имени модуля, нэймпспейса, каталога, класса, например в /App/Auth/Domain/User или /App/Auth/UI/Controllers/UserController на слой указывает Domain и UI. Но это всё на уровне конвеншинов в именах. Они могут не соблюдаться, могут отсутствовать (часто когда используется фреймворк, структура каталогов которого не очень ложится на архитектуру и приоритет отдаётся фреймворку в именовании)
Есть ощущение, что класс CloudManager нарушает принцип SRP — это видно даже по нарисованной схеме, как будто бы нужно разделить на три разных класса.
Здесь принцип разделения по порождающей среде. Документы могут быть в виде файлов на жёстком диске, а могут быть в виде документов в облаке (у какого-либо из операторов). Таким образом есть 2 среды.
Набор операций может относится к той или иной среде. Общее между этими средами — это доменная модель.
Фигурными скобками я отметил сущности к котором относятся методы. Сервис FSManager не работает с сущностями Company, Signer — эти сущности порождаются только облаком, а облако одно для всех сущностей. Можно было бы сделать ещё большую декомпозицию, в рамках декорации сервиса CloudManager, но мне достаточно было приведённой.
Как, взглянув на проект, понять сколько тут слоев, и какой класс к какому слою относится? И где границы слоя.
Анализируя стэк вызова от UI до БД или точки интеграции.
Например, в MVC приложении, перейдя на страницу
— нажимаете какую-то кнопку, напирмер создать заказ. — это начальная точка стэка вызова
— ловите в отладчике точку останова в обработчике
— следуете по шагам до тех пор пока не провалитесь из контекста контроллера, в какой-либо вложенный/связанный контекст — это 1 слой
— во вложенном контексте так же следуете до вызова следующего вложенного контекста — это 2 слой
— выпоняете это до тех пор, пока не дойдёте до обращения к БД, файлу или точке интеграции (вызывающией связанную систему) — это конечная точка стэка вызова
— выполняете такой анализ для всех вызово вложенных контекстах во всех слоях, таким образом поняв к каким конечным точкам происходит обращение при клике заданной кнопки и через какие контексты происходит этот вызов
— выписав и увидев так все контексты вы можете сориентироваться какие слои они образуют, от каких можно отказаться, а какие можно объединить в один слой
- Вот Вы привели кратко теорию по DDD — а зачем? При проектировании Вашей системы вы DDD не использовали — я делаю этот вывод на том основании, что при описании процесса проектирования ни разу не были упомянуты ни единый язык, ни ограниченный контекст, ни остальные термины из DDD.
- Термин "анемичная модель" встречается в посте один раз — в заголовке. Те, кто знает, что это такое — видят, что в системе именно она и используется. Для тех же, кто не знает, было бы неплохо привести определение и показать, что Ваша система под него подпадает.
эту статью-методику я пишу один раз, чтобы на неё в дальнейшем ссылаться
написание подобных статей трудозатратно и на её написание ушло несколько недель и это кусочек от общей серии методик которые я собираюсь написать
поэтому сразу всё включить в эту статью не получилось и я решил зафиксироаться пока на текущей редакции, а потом дополнить её в соответствии с вопросами, поэтому добавляйте статью в закладки, она будет дополняться
про анемичную модель — я ещё добавлю описание в этой статье и ссылки на неё из этапов методики (пункт 3)
роль DDD здесь частична и используется для образования одного из слоёв (слой бизнес логики DocumentSDK), термины я выделил и выписал, чтобы в дальнейшем использовать их в этой статье. Подобные короткие локоничные определения вам будет не просто найти в интернете. Их я нашёл перелопатив Вернона и Эванса, так что если вам понадобятся, можете их в дальнейшем найти в этой статье.
так же с течением времени я свяжу эти определения и создам представление о том какую роль DDD принимает в проектировании многослойного приложения
написание подобных статей трудозатратно и на её написание ушло несколько недель и это кусочек от общей серии методик которые я собираюсь написать
поэтому сразу всё включить в эту статью не получилось и я решил зафиксироаться пока на текущей редакции, а потом дополнить её в соответствии с вопросами, поэтому добавляйте статью в закладки, она будет дополняться
про анемичную модель — я ещё добавлю описание в этой статье и ссылки на неё из этапов методики (пункт 3)
роль DDD здесь частична и используется для образования одного из слоёв (слой бизнес логики DocumentSDK), термины я выделил и выписал, чтобы в дальнейшем использовать их в этой статье. Подобные короткие локоничные определения вам будет не просто найти в интернете. Их я нашёл перелопатив Вернона и Эванса, так что если вам понадобятся, можете их в дальнейшем найти в этой статье.
так же с течением времени я свяжу эти определения и создам представление о том какую роль DDD принимает в проектировании многослойного приложения
Ну почему пример в начале интересной статьи такой мягко сказать ...?
Зачем хрущевку реконструировать в небоскреб? Мало того, это практически невозможно, и даже если попробовать то будет бесконечно дорого.
Может быть для тривиального процесса (больше даже производственного нежели обработки данных с участием человека) можно построить в мозгу всю визуальную схему, не спорю.
Но для сложных систем и особенно с участием социума, человека и государства — только декомпозиция, иначе рискуете долго создавать монстра и еще дольше потом его настраивать, а к тому времени и нужда в нем отпадет.
Попробуйте посмотреть как технологические процессы в производстве описываются — от маршрутных карт до карты технологической операции. Работает уже сотни лет и легко формализуется.
Зачем хрущевку реконструировать в небоскреб? Мало того, это практически невозможно, и даже если попробовать то будет бесконечно дорого.
Цель: наш мозг по прежнему является самой эффективной нейросетью, поэтому для качественного моделирования необходимо будет поместить всю логику в одну или несколько голов, для последующей обработки всей информации и генерации программных моделей. Для этого необходимо собрать информацию о процессах таким образом, чтобы визуально представлять в уме то как они работают.
Может быть для тривиального процесса (больше даже производственного нежели обработки данных с участием человека) можно построить в мозгу всю визуальную схему, не спорю.
Но для сложных систем и особенно с участием социума, человека и государства — только декомпозиция, иначе рискуете долго создавать монстра и еще дольше потом его настраивать, а к тому времени и нужда в нем отпадет.
Попробуйте посмотреть как технологические процессы в производстве описываются — от маршрутных карт до карты технологической операции. Работает уже сотни лет и легко формализуется.
Эта статья прежде всего ориентирована на разработку корпоративных приложений, но возможно может быть использована в любом месте, где можно использовать объектно ориентированный подход.
Информационные технологии тем и хороши, что здесь как раз можно хрущёвку превратить небоскрёб. Под этим надо понимать программный продукт, которым пользуется бизнес-пользователь.
1. Берётся хрущевка
2. Проводится функциональный анализ -> выделяется документация, все возможные виды кейсов действий пользователя, тест кейсы, что формируется в тз
3. Проводится технический анализ, выделяются структуры БД, слои, настройки, инфораструктура, точки интеграции.
4. Дальше 2 пути, либо постепенный рефакторинг, либо waterflall проект
Когда я работал над проектом, я выбрал waterfall. Получился один марафон в 2 недели, когда я полностью переписал всю систему, которая инкрементно копила функционал в течение почти года. Далее замена у пользователей одной версии на другую и вот — небоскрёб, на работу по ошибкам уходило 0 минут в неделю.
Информационные технологии тем и хороши, что здесь как раз можно хрущёвку превратить небоскрёб. Под этим надо понимать программный продукт, которым пользуется бизнес-пользователь.
1. Берётся хрущевка
2. Проводится функциональный анализ -> выделяется документация, все возможные виды кейсов действий пользователя, тест кейсы, что формируется в тз
3. Проводится технический анализ, выделяются структуры БД, слои, настройки, инфораструктура, точки интеграции.
4. Дальше 2 пути, либо постепенный рефакторинг, либо waterflall проект
Когда я работал над проектом, я выбрал waterfall. Получился один марафон в 2 недели, когда я полностью переписал всю систему, которая инкрементно копила функционал в течение почти года. Далее замена у пользователей одной версии на другую и вот — небоскрёб, на работу по ошибкам уходило 0 минут в неделю.
То как вы сейчас написали — это не превратить (реконструировать, модернизировать, улучшить, ухудшить и т.п.) хрущевку в небоскреб. Это строительство с нуля небоскреба, потому что у него всё другое — начиная от фундамента, заканчивая вентиляцией.
При этом, невозможно оставить за скобками вопрос, а зачем собственно хрущевку реконструировать в небоскреб? Спускаясь на нашу грешную землю, сколько ругали товарища Хрущева за эти бедные пятиэтажки, которые решили проблему Москвы, в которой тогда 90% квартир были коммуналки, а затем еще и простояли 50 лет (кстати в бывшей ГДР их реконструируют с сохранением этажности и они еще 50 лет прослужат).
Чтобы расселить 5-этажку площадью 2,5 тыс. кв. м сейчас строят многоэтажку 10 тыс. кв. м.
Вопрос — как будут называть нынешних руководителей города через 50-60 лет, когда эти многоэтажки отслужат свое и чтобы расселить людей надо будет еще в 2-3 раза увеличить высоту и/или плотность застройки.
Именно поэтому как пример для начала статьи крайне неудачен.
При этом, невозможно оставить за скобками вопрос, а зачем собственно хрущевку реконструировать в небоскреб? Спускаясь на нашу грешную землю, сколько ругали товарища Хрущева за эти бедные пятиэтажки, которые решили проблему Москвы, в которой тогда 90% квартир были коммуналки, а затем еще и простояли 50 лет (кстати в бывшей ГДР их реконструируют с сохранением этажности и они еще 50 лет прослужат).
Чтобы расселить 5-этажку площадью 2,5 тыс. кв. м сейчас строят многоэтажку 10 тыс. кв. м.
Вопрос — как будут называть нынешних руководителей города через 50-60 лет, когда эти многоэтажки отслужат свое и чтобы расселить людей надо будет еще в 2-3 раза увеличить высоту и/или плотность застройки.
Именно поэтому как пример для начала статьи крайне неудачен.
«более лучшей» — ну прям сразу Лена из Иванова вспомнилась! Уж сколько все смеялись над этим словосочетанием по всему рунету, а вот поди ж ты, и тут оно
Ваша статья мне очень понравилась, поскольку сразу же нашла отклик в моем собственном опыте и припомнились предыдущие обсуждения по теме.
Есть у меня такое хобби — собирать по статьям мудрые высказывания людей (в том числе из комментариев), как говорится «все уже сказано до нас», поэтому просто приведу цитаты которые на мой взгляд стоит упомянуть в контексте данной статьи.
И еще немного от себя.
«Под архитектурным слоем подразумевается определённый набор логики, то есть деталей приложения, которые позволяют реализовать пространство прикладных задач заданного уровня» — здесь Вы скорее всего даете определение DSL, и в частности Языково-ориентированное программирование(LOP). При этом, я был бы рад что бы эталоном построения архитектуры стал LOP.
Есть у меня такое хобби — собирать по статьям мудрые высказывания людей (в том числе из комментариев), как говорится «все уже сказано до нас», поэтому просто приведу цитаты которые на мой взгляд стоит упомянуть в контексте данной статьи.
цель -> архитектура данных -> код. Здесь порядок менять ни в коем случае нельзя!
Разработчики сосредоточены на том, чтобы соорудить ограждения вокруг каждого класса, не особо задумываясь над тем, какие группы классов в совокупности формируют отдельную, многократно используемую, целостную логическую единицу.
Копирование сущностей реального мира и попытка приклеить к ним потом скотчем поведение — это одна из самых распространенных ошибок ОО-дизайна.
ООП-проекты обычно выглядят не как качественно спроектированные хранилища данных, а как огромные спагетти-графы объектов, указывающих друг на друга, и методы, получающие огромные списки аргументов. Когда вы начинаете проектировать объекты Context просто для того, чтобы урезать количество передаваемых туда-сюда аргументов, то понимаете, что пишете настоящий ООП-код уровня Enterprise.
Термин «служба» в мире разработки перегружен различными значениями, но в данной тематике, это обозначает небольшой класс, не представляющий конкретного человека, место или вещь в проектируемом приложении, но включающий в себя какие-то процессы.
Ну да, ведь у нас уже все напилено, что бы решать исключительно бизнес-задачи… а стойте, не напилено же! Если реализовывать строго по одной бизнес-задаче за раз, все очень быстро поломается.
В любом бизнесе НУЖНА МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ.
Если вам её не дают, обратитесь к непосредственному начальнику. Если вам говорят, что её нет, не верьте. Она есть, просто кто-то должен упорядочить хаос. Есть такие люди – конструкторы, проектировщики… они как бы должны. Еще раз: вам нужна модель. Иначе вы и ваш софт умрете. Поддерживать тучу глобализмов невозможно. Либо так: надо уволиться раньше, чем он умрет.Но проблема вот в чем. Разработать модель бизнес-процесса очень сложно. Бизнес постоянно меняется и это не математика (не создали ещё такой). Математики здесь опустили лапки и сейчас предпочитают принимать зачеты у студентов в ВУЗах. Поэтому прикладным программистам приходится “как-нибудь так”, как говорила незабвенная Масяня.
Мы должны задавать вопросы и требовать от экспертов более подробного описания их терминологии, либо смены формулировок, или даже использовать некие аналогии. Одна из моих любимых «игр» — это спросить экспертов о том, как бы они делали свои задачи в отсутствие компьютера. Что будет действиями, а что объектами, предметами, концепциями или существительными?
Процесс разработки ПО — это перевод описания и требований предметной области на формальный язык. Для упрощения процесса и устранения неточностей разработчики должны создавать, развивать и использовать язык предметной области
Разработчики, позволяющие себе неточности в речи, пренебрежение терминами, игнорирующие четкие определения, просто не понимают сути того, что они делают.
Опытные разработчики, когда видят задачу, не ломятся сразу херачить код, а сначала внимательно подумывают, как можно эту задачу декомпозировать на части, так чтобы каждая из частей получилась небольшой, а взаимодействие между ними было максимально простым.
Мне кажется, это остановка на полпути для программиста — главная задача которого автоматизировать выполнение операций людьми с помощью компьютера — не иметь возможности или не научиться автоматизировать собственные операции.
И еще немного от себя.
«Под архитектурным слоем подразумевается определённый набор логики, то есть деталей приложения, которые позволяют реализовать пространство прикладных задач заданного уровня» — здесь Вы скорее всего даете определение DSL, и в частности Языково-ориентированное программирование(LOP). При этом, я был бы рад что бы эталоном построения архитектуры стал LOP.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Методика проектирования архитектурных слоев на основе анемичной модели и DDD