0 просмотренных постов скрыто
Пятничный мем
Показать полностью
1
Собираем игры от 1с
Всем привет, 3 месяца назад я сделал ответный пост на тему коллекционирования серии от 1с по номерам
Время пролетело незаметно, коллекция немножко дополнолилась
+ как оказалось, первые игры выходили в тонких коробочках и были без номеров..
Кто хочет поностальгировать, вспомнить игры в которые играл или может не играл, но о которых слышал, узнать более детально про игры от 1с с серией номеров, готов выложить новое фото того, что удалось собрать
Коллекция теперь включает и игры в тонких коробочках, правда пока ещё не полностью
Напишите в комментарии, было бы Вам интересно узнать полную серию, увидеть по итогу полную коллекцию игр, так же готов отснять образы кому нужны сами игры из перечня того, что есть
Пишите в комментарии, делать ли дополнительный пост про коллекцию
Что я выбрал?
После прошлого поста многие писали: «Зачем выбирать? Развивай и 1С, и Unity одновременно».
Так не работает.
Чтобы сделать сильный образовательный продукт, недостаточно время от времени переключаться между двумя направлениями. Нужно глубоко погружаться в тему, изучать ее, собирать материалы, писать программу, делать контент. А если пытаться одинаково хорошо развивать и 1С, и Unity, то в итоге нормально не получится ни там, ни там.
Я это уже проходил.
При этом я точно знаю, чем хочу заниматься до конца жизни:
образованием, блогерством и играми
И если выбирать, вокруг какой темы строить образовательные продукты в будущем, — это Unity и игры в целом.
Я пересмотрел ваши комментарии, ответы из анкет обратной связи по курсу и результаты двух потоков.
Поэтому решение такое:
До конца 2026 года я оставляю запланированный поток по «Чистой архитектуре и DDD для 1С программистов» и полностью меняю программу курса.
Из минусов — придется переписать примерно 60%. Это около 150 рабочих часов.
Из плюсов — в курсе останется только то, что действительно нужно 1С программистам в работе.
БОльшую часть про Unity убираю, чтобы не тратить время и силы участников на то, что им не нужно, и не забивать голову лишней информацией.
Но полностью Unity из курса не исчезнет
Некоторые архитектурные приемы невозможно нормально показать в 1С — язык и сама платформа просто не позволяют это сделать
Поэтому другой стек останется ровно там, где 1С-разработчику важно увидеть, как это вообще должно работать.
А дальше появится отдельный большой блок о том, как все это применить уже в 1С: написать подсистему с нормальными границами, слоями и доменом по DDD, а затем встроить ее в типовую конфигурацию.
И на этом останавливаюсь.
Потихоньку развиваю отдельное направление по Unity. Со следующего года весь фокус в образовательных продуктах постепенно уйдет туда.
Будет ли этот поток по «Чистой архитектуре и DDD для 1С программистов» последним или предпоследним — пока не знаю 🤷♂️
Сегодня допиливаю новую программу. Завтра покажу, что получилось, а вы скажете, как вам.
Показать полностью
Моя идея провалилась
Закончился второй поток курса «Чистая архитектура на Unity», и теперь признаю официально: 1Сникам не нужны игры.
Курс я разрабатывал ради большой идеи. Даже, наверное, ради голубой мечты.
Я хотел не просто научить людей архитектуре, а показать им новый стек. Чтобы 1Сники попробовали Unity, сделали игры и нашли в этом что-то новое для себя. Увидели, что с текущими возможностями ИИ, новый стек не является преградой и уже сегодня можно писать приложения на любом языке. Единственное, что точно нужно понимать и применить, — это правила хорошей архитектуры.
Но все пошло не по плану 😭
Да, люди проходят блоки по чистой архитектуре и DDD, получают то, за чем пришли. В анкетах обратной связи участники пишут, что после курса:
стали выносить логику из форм в отдельные модули и сервисы, стали разделять код по слоям, стали думать юзкейсами и использовать юзкейсы, начинают смотреть на доработки через контексты и их границы.
Но дальше не идут… единицы выкладывают игры. Даже те, кто покупал полный курс.
Один из студентов VIP-тарифа мне так и написал:
«Жень, дальше не иду, мне достаточно. Я получил все, что хотел».
На последнем стриме по DDD я открыл предзапись. Там ровно та же картина: почти все записываются на архитектуру. Несколько человек — на VIP. Игры опять никому не нужны.
При этом на каждом потоке каким-то загадочным образом появляются люди, которые много лет разрабатывают игры на Unity. Они не 1Сники. Откуда они меня находят — до сих пор не понимаю. Но они стабильно учатся у меня.
Теперь думаю, что делать дальше.
👉 Первый вариант — переделать курс и оставить только то, зачем на самом деле приходят 1С-разработчики.
Убрать идею «давайте напишем игру». Вместо этого в финале курса с нуля спроектировать подсистему в 1С по правилам чистой архитектуры: с нормальными границами, слоями и доменом по DDD. Интегрировать подсистему в типовую конфигурацию и посмотреть, как все это работает в связке с типовыми решениями 1С
👉 Второй вариант — полностью сконцентрироваться на Unity и работать уже с теми, кому, действительно, нужны игры, потому что, честно говоря, игры все-таки манят меня гораздо сильнее, чем идея заниматься чистой архитектурой в 1С.
Пока не знаю, какое решение правильное.
Дам себе пару-тройку дней подумать. Ну и, конечно, послушаю вас. Делитесь в комментариях своими мыслями.
Показать полностью
Пятничный мем
Показать полностью
1
Пример DDD и Чистой Архитектуры в 1С
На стриме разбираем применимость DDD и чистой архитектуры в 1С: — ищем слои и целостные пользовательские сценарии — выясняем, почему формы становятся «толстыми» — где в типовых решениях спрятаны проверки, бизнес-правила и инварианты, — как явный application-слой и агрегаты помогают сделать код выразительнее, надежнее и удобнее для программного переиспользования
Показать полностью
Как отделить бизнес-логику планирования сборок от типового кода 1С
Представим задачу: нужно определить, какие комплекты собирать в первую очередь, если запасов комплектующих недостаточно для выполнения всего плана продаж.
При расчёте необходимо учитывать:
— уже имеющиеся готовые комплекты;
— остатки комплектующих;
— план продаж;
— приоритеты компании.
На выходе должна получиться обоснованная программа сборки: что и в каком количестве собирать, чтобы направить ограниченные ресурсы на наиболее важные или прибыльные позиции.
При этом алгоритм не должен полностью заменять решение пользователя. Рекомендации можно проверить, скорректировать и только после этого передать готовый план в УТ11.
С архитектурной точки зрения основная проблема заключается в том, что бизнес-логика в 1С часто распределена между формой, общими модулями, ПередЗаписью, ОбработкойПроверкиЗаполнения, ОбработкойПроведения и другими обработчиками.
В результате один бизнес-сценарий приходится восстанавливать по десяткам процедур.
На примере планирования сборок можно разобрать:
👉 почему бизнес-логика в 1С часто оказывается размазана между формой, общими модулями, ПередЗаписью, ОбработкойПроверкиЗаполнения, ОбработкойПроведения и другими обработчиками;
👉 где заканчивается обычная проверка данных и начинается настоящее бизнес-правило;
👉 что оставить в форме, а что перенести в прикладной сценарий и доменную модель;
👉 чем Transaction Script и Active Record (а это ровно те принципы, на которых построен типовой код) отличаются от модели с агрегатом;
👉 как собрать сценарий так, чтобы бизнес-логику было видно в коде, а не приходилось восстанавливать по десяткам обработчиков;
👉 как сделать решение проще для изменения, тестирования и подключения к типовой УТ11
Главная задача DDD и чистой архитектуры здесь не в том, чтобы создать как можно больше классов и модулей. Смысл в том, чтобы сделать бизнес-правила явными, собрать их в понятную модель и не размазывать по техническим обработчикам.
23 июля в 19:00 по московскому времени проведу онлайн-разбор этой задачи. Во время встречи покажу реализацию расширения, структуру прикладного сценария и подход к выделению доменной модели.
Запись встречи планируется сохранить. Исходный код расширения отдам участникам прямого эфира.
Показать полностью
1