это не диаграмма классов, вместо классов здесь сущности предметной области. Сущности предметной области соедниняются с точками интеграции. Так, если вы столкнулись с ошибкой при выполнении какого-то действия — вы можете быстро найти точку интеграции в которой вероятнее всего ошибка. Иначе вам придётся сёрфить по множеству классов
Нововведение очень не удобно. Редактирование очень отличается от традиционного, как например в ворде, когда есть одно пространство — лист, и на нём происходит всё редактирование. Теперь этого нет. Взять и выделить через CTRL+A весь текст теперь не возможно. Вообще процесс нестандартный. Это какой-то VIX-конструктор для статей
сейчас подумал, вообще архитектурный слой нет проблем использовать в любом проекте, где используется ООП язык, так как анемичная модель — это частный случай применения ООП. Любой функциональный метод можно обернуть в ООП обёртку из которой можно сформировать анемичную модель.
По сути, вы выполнили такие технологические внедрения как:
— CI/DI
— демостенды (которые позволяют выполнять проверенную приёмку заказчиком)
— разделение на микросервисы
— замена Legacy монолита на адаптацию Spring+Comunda
С точки зрения реальности, в использовании данных технологий нет ничего нового и есть проекты 2014 года, в которых уже замечательно реализуются микросервисы, то есть потенциал уже давно обоснован, как и с другими технологиями.
Вы выполнили рациональные внедрения и получили ожидаемый результат. Сами по себе идеи не новы. Поздравляю вас. Хорошо было бы узнать как вы сдавали релизы заказчику без демостанедов ранее и как ваша жизнь изменилась после.
И интересно узнать более подробно, как вам удалось обосновать подобные внедрения? Ведь контакт менеджера с клиентом можно было бы реализовать в виде набора костылей на скорую руку, как это чаще всего происходит в российском ИТ :)
чтобы дать ответ как у вас, можно даже не иметь никакого опыта в разработке
зайдите для начала на википедию, прочитайте определение Архитектура ПО и всё что в статье, потом можем пообщаться
Спасибо, даёт общее представление.
А как по вашему, может ли конфигурация 1C Конвертация данных считаться ETL системой? Там по сути то же самое просходит its.1c.ru/db/metod8dev/content/2943/hdoc
Я вчитался в статью и вот что я вижу.
1. У вас была старая команда, которая сделала проект как можно быстрее, но из-за этого накопила тех. долга, на который бизнес не хотел выделять времени.
2. Из-за тех.долга в команде большая токсичность плюс бизнес влезает в ИТ процессы, видимо чтобы ускорить работу.
3. Из-за тех.долга ваш проект напоминает ведро с гайками, поэтому релиз каждый раз долго готовится
Что вы сделали
1. Решили перейти на другой стэк, вместо выполнения бэклога. Бизнес вложил деньги в методику соседнего проекта
2. Ретро решили проводить только в карайних случаях. Хотя пишете что ретро проводите раз в месяц, что нормально, если спринт 2 недели
3. Разогнали старую команду и наняли новую
4. Централизовали роль архитектора
5. Отказались от спринтов и заменили их на некие due-даты (кстати что это?)
Интересно откуда вы пригласили архитектора (из старой команды, из соседнего проекта или со стороны).
Получил ли руководитель соседнего проекта повышение и куда пошёл руководитель старого легаси проекта.
И как вам удаётся контроллировать бизнес? Так как если появится менеджер от бизнеса, скажет впаять вот эту кнопку в релиз или какую-то таблицу в бд, что вы будете делать? :)
Эта статья прежде всего ориентирована на разработку корпоративных приложений, но возможно может быть использована в любом месте, где можно использовать объектно ориентированный подход.
Информационные технологии тем и хороши, что здесь как раз можно хрущёвку превратить небоскрёб. Под этим надо понимать программный продукт, которым пользуется бизнес-пользователь.
1. Берётся хрущевка
2. Проводится функциональный анализ -> выделяется документация, все возможные виды кейсов действий пользователя, тест кейсы, что формируется в тз
3. Проводится технический анализ, выделяются структуры БД, слои, настройки, инфораструктура, точки интеграции.
4. Дальше 2 пути, либо постепенный рефакторинг, либо waterflall проект
Когда я работал над проектом, я выбрал waterfall. Получился один марафон в 2 недели, когда я полностью переписал всю систему, которая инкрементно копила функционал в течение почти года. Далее замена у пользователей одной версии на другую и вот — небоскрёб, на работу по ошибкам уходило 0 минут в неделю.
Я здесь кратко упоминаю в шаге 1 о тест-кейсах. Конечно их роль огромна, как и роль тестировщика. Изначально в статье были пункты Реализация и Тестирование, а в аналитике было подробное описание того как составлять скрипты, одновременно являющиеся и задачами на разработку по BDD и тест кейсами для приёмки таких задач, но это выросло в 2 отдельных статьи, которые я сейчас параллель пишу. Так что всё впереди)
Есть ощущение, что класс CloudManager нарушает принцип SRP — это видно даже по нарисованной схеме, как будто бы нужно разделить на три разных класса.
Здесь принцип разделения по порождающей среде. Документы могут быть в виде файлов на жёстком диске, а могут быть в виде документов в облаке (у какого-либо из операторов). Таким образом есть 2 среды.
Набор операций может относится к той или иной среде. Общее между этими средами — это доменная модель.
Фигурными скобками я отметил сущности к котором относятся методы. Сервис FSManager не работает с сущностями Company, Signer — эти сущности порождаются только облаком, а облако одно для всех сущностей. Можно было бы сделать ещё большую декомпозицию, в рамках декорации сервиса CloudManager, но мне достаточно было приведённой.
Как, взглянув на проект, понять сколько тут слоев, и какой класс к какому слою относится? И где границы слоя.
Анализируя стэк вызова от UI до БД или точки интеграции.
Например, в MVC приложении, перейдя на страницу
— нажимаете какую-то кнопку, напирмер создать заказ. — это начальная точка стэка вызова
— ловите в отладчике точку останова в обработчике
— следуете по шагам до тех пор пока не провалитесь из контекста контроллера, в какой-либо вложенный/связанный контекст — это 1 слой
— во вложенном контексте так же следуете до вызова следующего вложенного контекста — это 2 слой
— выпоняете это до тех пор, пока не дойдёте до обращения к БД, файлу или точке интеграции (вызывающией связанную систему) — это конечная точка стэка вызова
— выполняете такой анализ для всех вызово вложенных контекстах во всех слоях, таким образом поняв к каким конечным точкам происходит обращение при клике заданной кнопки и через какие контексты происходит этот вызов
— выписав и увидев так все контексты вы можете сориентироваться какие слои они образуют, от каких можно отказаться, а какие можно объединить в один слой
эту статью-методику я пишу один раз, чтобы на неё в дальнейшем ссылаться
написание подобных статей трудозатратно и на её написание ушло несколько недель и это кусочек от общей серии методик которые я собираюсь написать
поэтому сразу всё включить в эту статью не получилось и я решил зафиксироаться пока на текущей редакции, а потом дополнить её в соответствии с вопросами, поэтому добавляйте статью в закладки, она будет дополняться
про анемичную модель — я ещё добавлю описание в этой статье и ссылки на неё из этапов методики (пункт 3)
роль DDD здесь частична и используется для образования одного из слоёв (слой бизнес логики DocumentSDK), термины я выделил и выписал, чтобы в дальнейшем использовать их в этой статье. Подобные короткие локоничные определения вам будет не просто найти в интернете. Их я нашёл перелопатив Вернона и Эванса, так что если вам понадобятся, можете их в дальнейшем найти в этой статье.
так же с течением времени я свяжу эти определения и создам представление о том какую роль DDD принимает в проектировании многослойного приложения
Я предпочитаю работать в консоли и большая часть команд и советов в этой заметке будет про консольный клиент. Это своего рода первая рекомендация — используйте консольный клиент для ежедневной работы с репозиторием и регулярно его обновляйте. В консольном клиенте в первую очередь появляются новые возможности и исправления ошибок.
Какая-то странная у вас аргументация.
Ни разу не сталкивался с ошибками git клиента
А вот то что в VS 2019 появился squash, мне во многом облегчило жизнь
Чувство, что меня троллят, но отвечу)
Слой архитектуры воспринимается, как будто есть слой архитектуры, а есть ещё какой-то слой (не архитектуры)
Когда я говорю Архитектурный слой, подразумевается, что сама архитектура состоит из слоёв
Спасибо за ссылку, почитаю.
А вы можете сейчас сказать на сколько отличается определение архитектурного слоя в этой книге и в статье?
Чем-то можно определение дополнить?
Суть в том, чтобы выработать короткое и понятное определение, чтобы всем ими пользоваться.
это не диаграмма классов, вместо классов здесь сущности предметной области. Сущности предметной области соедниняются с точками интеграции. Так, если вы столкнулись с ошибкой при выполнении какого-то действия — вы можете быстро найти точку интеграции в которой вероятнее всего ошибка. Иначе вам придётся сёрфить по множеству классов
— CI/DI
— демостенды (которые позволяют выполнять проверенную приёмку заказчиком)
— разделение на микросервисы
— замена Legacy монолита на адаптацию Spring+Comunda
С точки зрения реальности, в использовании данных технологий нет ничего нового и есть проекты 2014 года, в которых уже замечательно реализуются микросервисы, то есть потенциал уже давно обоснован, как и с другими технологиями.
Вы выполнили рациональные внедрения и получили ожидаемый результат. Сами по себе идеи не новы. Поздравляю вас. Хорошо было бы узнать как вы сдавали релизы заказчику без демостанедов ранее и как ваша жизнь изменилась после.
И интересно узнать более подробно, как вам удалось обосновать подобные внедрения? Ведь контакт менеджера с клиентом можно было бы реализовать в виде набора костылей на скорую руку, как это чаще всего происходит в российском ИТ :)
«Ну рально то что вы описываете это не об архитектуре» — чувствуется 15 летний опыт…
не пишите сюда больше
удачи!
зайдите для начала на википедию, прочитайте определение Архитектура ПО и всё что в статье, потом можем пообщаться
А как по вашему, может ли конфигурация 1C Конвертация данных считаться ETL системой? Там по сути то же самое просходит
its.1c.ru/db/metod8dev/content/2943/hdoc
1. У вас была старая команда, которая сделала проект как можно быстрее, но из-за этого накопила тех. долга, на который бизнес не хотел выделять времени.
2. Из-за тех.долга в команде большая токсичность плюс бизнес влезает в ИТ процессы, видимо чтобы ускорить работу.
3. Из-за тех.долга ваш проект напоминает ведро с гайками, поэтому релиз каждый раз долго готовится
Что вы сделали
1. Решили перейти на другой стэк, вместо выполнения бэклога. Бизнес вложил деньги в методику соседнего проекта
2. Ретро решили проводить только в карайних случаях. Хотя пишете что ретро проводите раз в месяц, что нормально, если спринт 2 недели
3. Разогнали старую команду и наняли новую
4. Централизовали роль архитектора
5. Отказались от спринтов и заменили их на некие due-даты (кстати что это?)
Интересно откуда вы пригласили архитектора (из старой команды, из соседнего проекта или со стороны).
Получил ли руководитель соседнего проекта повышение и куда пошёл руководитель старого легаси проекта.
И как вам удаётся контроллировать бизнес? Так как если появится менеджер от бизнеса, скажет впаять вот эту кнопку в релиз или какую-то таблицу в бд, что вы будете делать? :)
Информационные технологии тем и хороши, что здесь как раз можно хрущёвку превратить небоскрёб. Под этим надо понимать программный продукт, которым пользуется бизнес-пользователь.
1. Берётся хрущевка
2. Проводится функциональный анализ -> выделяется документация, все возможные виды кейсов действий пользователя, тест кейсы, что формируется в тз
3. Проводится технический анализ, выделяются структуры БД, слои, настройки, инфораструктура, точки интеграции.
4. Дальше 2 пути, либо постепенный рефакторинг, либо waterflall проект
Когда я работал над проектом, я выбрал waterfall. Получился один марафон в 2 недели, когда я полностью переписал всю систему, которая инкрементно копила функционал в течение почти года. Далее замена у пользователей одной версии на другую и вот — небоскрёб, на работу по ошибкам уходило 0 минут в неделю.
Здесь принцип разделения по порождающей среде. Документы могут быть в виде файлов на жёстком диске, а могут быть в виде документов в облаке (у какого-либо из операторов). Таким образом есть 2 среды.
Набор операций может относится к той или иной среде. Общее между этими средами — это доменная модель.
Фигурными скобками я отметил сущности к котором относятся методы. Сервис FSManager не работает с сущностями Company, Signer — эти сущности порождаются только облаком, а облако одно для всех сущностей. Можно было бы сделать ещё большую декомпозицию, в рамках декорации сервиса CloudManager, но мне достаточно было приведённой.
Анализируя стэк вызова от UI до БД или точки интеграции.
Например, в MVC приложении, перейдя на страницу
— нажимаете какую-то кнопку, напирмер создать заказ. — это начальная точка стэка вызова
— ловите в отладчике точку останова в обработчике
— следуете по шагам до тех пор пока не провалитесь из контекста контроллера, в какой-либо вложенный/связанный контекст — это 1 слой
— во вложенном контексте так же следуете до вызова следующего вложенного контекста — это 2 слой
— выпоняете это до тех пор, пока не дойдёте до обращения к БД, файлу или точке интеграции (вызывающией связанную систему) — это конечная точка стэка вызова
— выполняете такой анализ для всех вызово вложенных контекстах во всех слоях, таким образом поняв к каким конечным точкам происходит обращение при клике заданной кнопки и через какие контексты происходит этот вызов
— выписав и увидев так все контексты вы можете сориентироваться какие слои они образуют, от каких можно отказаться, а какие можно объединить в один слой
написание подобных статей трудозатратно и на её написание ушло несколько недель и это кусочек от общей серии методик которые я собираюсь написать
поэтому сразу всё включить в эту статью не получилось и я решил зафиксироаться пока на текущей редакции, а потом дополнить её в соответствии с вопросами, поэтому добавляйте статью в закладки, она будет дополняться
про анемичную модель — я ещё добавлю описание в этой статье и ссылки на неё из этапов методики (пункт 3)
роль DDD здесь частична и используется для образования одного из слоёв (слой бизнес логики DocumentSDK), термины я выделил и выписал, чтобы в дальнейшем использовать их в этой статье. Подобные короткие локоничные определения вам будет не просто найти в интернете. Их я нашёл перелопатив Вернона и Эванса, так что если вам понадобятся, можете их в дальнейшем найти в этой статье.
так же с течением времени я свяжу эти определения и создам представление о том какую роль DDD принимает в проектировании многослойного приложения
и архитектурной документации
Какая-то странная у вас аргументация.
Ни разу не сталкивался с ошибками git клиента
А вот то что в VS 2019 появился squash, мне во многом облегчило жизнь
Слой архитектуры воспринимается, как будто есть слой архитектуры, а есть ещё какой-то слой (не архитектуры)
Когда я говорю Архитектурный слой, подразумевается, что сама архитектура состоит из слоёв
А вы можете сейчас сказать на сколько отличается определение архитектурного слоя в этой книге и в статье?
Чем-то можно определение дополнить?
Суть в том, чтобы выработать короткое и понятное определение, чтобы всем ими пользоваться.