Pull to refresh

Comments 16

Хорошее описание хорошей архитектуры.

С моментом про слои приложения я несколько не согласен. Вообще со слоями весьма спорная тема. Где-то слои есть, где-то нет. По мне слои в большинстве приложений идут от железа к бизнес логике:
работа с процессором > работа с операционкой > работа с БД > прием, валидация данных > логика доступа > бизнес логика > пользовательский интерфейс.

Самое сложное для большинства компаний на начальных этапах это понять, что разработчика нужно обучить системе, рассказать про структуры данных, основные сущности и тд… и вообще вести документацию по всем сущностям.
80% всех проблем от того, что нет понимания работы системы. Что уже сделано и где. Начинаются задвоения логики и каждая ветка логики начинает расходиться с реальностью.
Давние сорудники считают что все и так понятно, читай код и все поймешь, а новый сотрудник даже если он супер спец, просто не в состоянии догадаться для чего нужна каждая из 1500 таблиц в БД и нюансы работы каждого поля.

И еще момент забыли: кладезь ценных знаний — тестировщик. Тестировщик не просто человек, пытающийся сломать систему или выявить неудобства. Это «друид», который знает всякие нюансы разных фич. И стоило бы чаще принимать у таких людей мастер-классы по работе системы. Если конечно вы не единственный разраб и всю систему сами написали.

Также можно добавить, что DDD предполагает ведение документации, которая не отстает от кода. Намного легче вникать в проекты, где подобная документация всё-таки есть

Скорее в DDD сам код и есть документация прежде всего.

по документации скоро будет несколько статей по опыту создания предметно-ориентированной пользовательской документации
и архитектурной документации
Я здесь кратко упоминаю в шаге 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 слой
— выпоняете это до тех пор, пока не дойдёте до обращения к БД, файлу или точке интеграции (вызывающией связанную систему) — это конечная точка стэка вызова
— выполняете такой анализ для всех вызово вложенных контекстах во всех слоях, таким образом поняв к каким конечным точкам происходит обращение при клике заданной кнопки и через какие контексты происходит этот вызов
— выписав и увидев так все контексты вы можете сориентироваться какие слои они образуют, от каких можно отказаться, а какие можно объединить в один слой
  1. Вот Вы привели кратко теорию по DDD — а зачем? При проектировании Вашей системы вы DDD не использовали — я делаю этот вывод на том основании, что при описании процесса проектирования ни разу не были упомянуты ни единый язык, ни ограниченный контекст, ни остальные термины из DDD.
  2. Термин "анемичная модель" встречается в посте один раз — в заголовке. Те, кто знает, что это такое — видят, что в системе именно она и используется. Для тех же, кто не знает, было бы неплохо привести определение и показать, что Ваша система под него подпадает.
эту статью-методику я пишу один раз, чтобы на неё в дальнейшем ссылаться
написание подобных статей трудозатратно и на её написание ушло несколько недель и это кусочек от общей серии методик которые я собираюсь написать
поэтому сразу всё включить в эту статью не получилось и я решил зафиксироаться пока на текущей редакции, а потом дополнить её в соответствии с вопросами, поэтому добавляйте статью в закладки, она будет дополняться

про анемичную модель — я ещё добавлю описание в этой статье и ссылки на неё из этапов методики (пункт 3)

роль DDD здесь частична и используется для образования одного из слоёв (слой бизнес логики DocumentSDK), термины я выделил и выписал, чтобы в дальнейшем использовать их в этой статье. Подобные короткие локоничные определения вам будет не просто найти в интернете. Их я нашёл перелопатив Вернона и Эванса, так что если вам понадобятся, можете их в дальнейшем найти в этой статье.
так же с течением времени я свяжу эти определения и создам представление о том какую роль DDD принимает в проектировании многослойного приложения
Ну почему пример в начале интересной статьи такой мягко сказать ...?

Зачем хрущевку реконструировать в небоскреб? Мало того, это практически невозможно, и даже если попробовать то будет бесконечно дорого.

Цель: наш мозг по прежнему является самой эффективной нейросетью, поэтому для качественного моделирования необходимо будет поместить всю логику в одну или несколько голов, для последующей обработки всей информации и генерации программных моделей. Для этого необходимо собрать информацию о процессах таким образом, чтобы визуально представлять в уме то как они работают.

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

Попробуйте посмотреть как технологические процессы в производстве описываются — от маршрутных карт до карты технологической операции. Работает уже сотни лет и легко формализуется.
Эта статья прежде всего ориентирована на разработку корпоративных приложений, но возможно может быть использована в любом месте, где можно использовать объектно ориентированный подход.

Информационные технологии тем и хороши, что здесь как раз можно хрущёвку превратить небоскрёб. Под этим надо понимать программный продукт, которым пользуется бизнес-пользователь.
1. Берётся хрущевка
2. Проводится функциональный анализ -> выделяется документация, все возможные виды кейсов действий пользователя, тест кейсы, что формируется в тз
3. Проводится технический анализ, выделяются структуры БД, слои, настройки, инфораструктура, точки интеграции.
4. Дальше 2 пути, либо постепенный рефакторинг, либо waterflall проект

Когда я работал над проектом, я выбрал waterfall. Получился один марафон в 2 недели, когда я полностью переписал всю систему, которая инкрементно копила функционал в течение почти года. Далее замена у пользователей одной версии на другую и вот — небоскрёб, на работу по ошибкам уходило 0 минут в неделю.
То как вы сейчас написали — это не превратить (реконструировать, модернизировать, улучшить, ухудшить и т.п.) хрущевку в небоскреб. Это строительство с нуля небоскреба, потому что у него всё другое — начиная от фундамента, заканчивая вентиляцией.
При этом, невозможно оставить за скобками вопрос, а зачем собственно хрущевку реконструировать в небоскреб? Спускаясь на нашу грешную землю, сколько ругали товарища Хрущева за эти бедные пятиэтажки, которые решили проблему Москвы, в которой тогда 90% квартир были коммуналки, а затем еще и простояли 50 лет (кстати в бывшей ГДР их реконструируют с сохранением этажности и они еще 50 лет прослужат).
Чтобы расселить 5-этажку площадью 2,5 тыс. кв. м сейчас строят многоэтажку 10 тыс. кв. м.
Вопрос — как будут называть нынешних руководителей города через 50-60 лет, когда эти многоэтажки отслужат свое и чтобы расселить людей надо будет еще в 2-3 раза увеличить высоту и/или плотность застройки.
Именно поэтому как пример для начала статьи крайне неудачен.

«более лучшей» — ну прям сразу Лена из Иванова вспомнилась! Уж сколько все смеялись над этим словосочетанием по всему рунету, а вот поди ж ты, и тут оно

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

цель -> архитектура данных -> код. Здесь порядок менять ни в коем случае нельзя!

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

Копирование сущностей реального мира и попытка приклеить к ним потом скотчем поведение — это одна из самых распространенных ошибок ОО-дизайна.

ООП-проекты обычно выглядят не как качественно спроектированные хранилища данных, а как огромные спагетти-графы объектов, указывающих друг на друга, и методы, получающие огромные списки аргументов. Когда вы начинаете проектировать объекты Context просто для того, чтобы урезать количество передаваемых туда-сюда аргументов, то понимаете, что пишете настоящий ООП-код уровня Enterprise.

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

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

В любом бизнесе НУЖНА МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ.
Если вам её не дают, обратитесь к непосредственному начальнику. Если вам говорят, что её нет, не верьте. Она есть, просто кто-то должен упорядочить хаос. Есть такие люди – конструкторы, проектировщики… они как бы должны. Еще раз: вам нужна модель. Иначе вы и ваш софт умрете. Поддерживать тучу глобализмов невозможно. Либо так: надо уволиться раньше, чем он умрет.Но проблема вот в чем. Разработать модель бизнес-процесса очень сложно. Бизнес постоянно меняется и это не математика (не создали ещё такой). Математики здесь опустили лапки и сейчас предпочитают принимать зачеты у студентов в ВУЗах. Поэтому прикладным программистам приходится “как-нибудь так”, как говорила незабвенная Масяня.

Мы должны задавать вопросы и требовать от экспертов более подробного описания их терминологии, либо смены формулировок, или даже использовать некие аналогии. Одна из моих любимых «игр» — это спросить экспертов о том, как бы они делали свои задачи в отсутствие компьютера. Что будет действиями, а что объектами, предметами, концепциями или существительными?

Процесс разработки ПО — это перевод описания и требований предметной области на формальный язык. Для упрощения процесса и устранения неточностей разработчики должны создавать, развивать и использовать язык предметной области

Разработчики, позволяющие себе неточности в речи, пренебрежение терминами, игнорирующие четкие определения, просто не понимают сути того, что они делают.

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

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


И еще немного от себя.
«Под архитектурным слоем подразумевается определённый набор логики, то есть деталей приложения, которые позволяют реализовать пространство прикладных задач заданного уровня» — здесь Вы скорее всего даете определение DSL, и в частности Языково-ориентированное программирование(LOP). При этом, я был бы рад что бы эталоном построения архитектуры стал LOP.
Sign up to leave a comment.

Articles