Хотели когда-нибудь примерить на себя костюмчик успешного архитектора из мира больших бизнесов? Ну тех, кто зарабатывает на лекциях и подкастах больше, чем на основной работе. Рецепт то не особенно сложный: пара успешных проектов и кул стори в интернетах. Впахивай и впаривай! Иногда в комплекте к костюму идут одноцветные тапочки…
В прошлой статье я рассказал, как мы пришли к DDD и про его очень важную особенность — единый язык, на котором легче и дешевле разговаривать с бизнесом. Еще мы рассмотрели разработку, ведомую моделью. Когда вначале стоит не выполненная по требованию фича, а абстрактная модель, созданная по требованиям и имеющая отражения в различных представлениях. Все эти области оперируют терминами единого языка и реализованы максимально похожими, чтобы каждый, кто будет работать с проектом, смог разобраться в любой из них.
Сегодня поговорим о том, как приручить непосредственно исходные коды программ, как они архитектурно представляются. Расскажу про идеи, которые мы используем для построения прозрачной и понятной модели, чтобы ее было легко развивать вместе с заказчиком. Эти подходы касаются и архитектуры, и хранения исходного кода, и вообще в целом вопросов разработки. Также расскажу про практические сложности. Формат статьи не позволяет включить огромное количество кейсов, поэтому приведу только два примера.
Давненько я не публиковал новостей по развитию инструмента описания архитектуры кодом. А похвастаться есть чем. Сегодня я исправлю свою досадную оплошность.
В Java можно объявлять переменные в классе, методе, блоке или конструкторе. В зависимости от варианта объявления, у переменной могут быть разные области видимости в программе, а сама переменная может относиться к статическому или нестатическому типу в зависимости от того, где она объявлена.
Основываясь на этих критериях, можно разделить все переменные в Java на следующие типы: локальные переменные, переменные экземпляра и переменные класса. Затемнение и сокрытие переменных происходит, когда оказываются одноименными две переменные в разных областях видимости (в локальной и глобальной области видимости, в родительских и дочерних классах). При таком сценарии используется значение той переменной, которая находится во внутренней области видимости, так как она затемняет/скрывает значение той переменной, что находится во внешней области видимости.
Привет! Продолжаем делиться опытом о том, как можно автоматизировать бизнес-процессы в банке с помощью Camunda. В прошлой статье мы рассказали об одном из проектов, который создали на базе Spring Boot с подключенной Camunda в качестве библиотеки. В этом материале расскажем об особенностях его тестирования.
Поговорим про тестирование моделей процессов Camunda, приведем примеры кода, конфигураций для запуска процессов в тестовой среде, а также поделимся best practice и некоторыми библиотеками, которые значительно облегчают тестирование процессов. Основная задача данного туториала – сэкономить время и упростить задачу командам разработчиков, которые создают приложения на SpringBoot и Camunda, а также тем, кто хочет начать покрывать модели процессов автотестами.
В статье "Пережить великую нехватку переменных" (Outliving the Great Variable Shortage) Тим Оттингер формулирует закон Кёрли:
«Переменная должна означать только что-то одно. Она не должна означать "что-то при таких-то условиях" и иметь разный смысл в разных обстоятельствах. Также она не должна иметь два смысла одновременно. "За двумя зайцами погонишься – ни одного не поймаешь". Переменная должна означать что-то одно все время своего существования»
Одни из важнейших характеристик качественного IT-продукта — отказоустойчивость и работоспособность под нагрузками. Когда речь идёт о пользовательских финансовых операциях, это важно вдвойне, а если к уравнению добавить хайлоад — втройне.
Я разрабатываю сервисы в команде платежей Ozon. Мы много времени уделяем тому, чтобы все транзакции были обработаны корректно, даже если речь идёт о нагрузке в 2к платежей в минуту (именно столько у нас было в пике в период ноябрьских распродаж). Кстати, сейчас, по результатам нагрузочного тестирования, мы выдерживаем 13к платежей в минуту.
Для этого мы готовимся заранее: пересматриваем архитектуру, дорабатываем сервисы, рефакторим код, кэшируем и оптимизируем базы данных. Серебряной пули тут нет, но могу поделиться техниками, которые помогли нам избежать возможных проблем, — будет полезно всем, кто готовит свои сервисы с прицелом на работоспособность под нагрузками.
Меня зовут Павел Плетнев, я разработчик в команде кредитных карт в Тинькофф. Хочу поделиться, как можно заранее оптимизировать работу с историей в Camunda или решить проблемы, если вдруг они появились.
Привет! Недавно мы разработали для российского банка и запустили сервис, который помогает пользователям при получении финансовых услуг. Как и всегда в финтехе, сервис должен был отвечать требованиям безопасности, отказоустойчивости и надежности. А для его внедрения нужно было решить еще одну интересную задачу – разобраться в бизнес-процессах банка и улучшить их автоматизацию, используя движок Camunda BPM.
Изучая задачу, мы выяснили, что материалов об автоматизации бизнес-процессов в Camunda немного, особенно на русском языке. Поделимся своим опытом реализации проекта на Camunda, Java и Spring Boot.
Материал будет полезен в первую очередь тем, кто начинает новый процесс на Camunda, а также тем, кто находится в поиске свежего взгляда на реализацию процессов в условиях кластера с микросервисами. Планируем далее продолжить эту тему и рассказать о тестировании моделей процессов. Продолжение здесь.
Masscan — быстрый сетевой сканер, который хорошо подходит для сканирования большого диапазона IP-адресов и портов. Мы немного доработали его, адаптировав под свои нужды.
Больше всего неудобств оригинала было связано с невозможностью собирать баннеры с HTTPS-серверов. А что такое современный веб без HTTPS? Особо ничего не насканируешь. Это и смотивировало нас изменить masscan. Как обычно бывает, одна маленькая доработка переросла в другую, обнаружились баги. Теперь мы хотим поделиться нашими наработками с сообществом. Все изменения, о которых пойдет речь, уже доступны в нашем репозитории на GitHub.
Привет Хабр! Пятничного тру ФП хардкора с Free Monad, Таглес Финал, Монад трансформерами, Refined Types, Smart Constructors и прочим таким вам в ленту. Хардкор сам себя в ленту не принесет так что погнали.
Гексагональная архитектура делит наш код на три основные части.
1) Primary Adapters,
2) Secondary Adapter
3) Logic aka Domain.
Всем привет! Меня зовут Игорь Савин, я frontend-разработчик в компании Домклик. На текущий момент у нас около 150 различных команд разработки, из которых большая часть связана с разработкой какого-либо фронтенда на HTML, CSS и Javascript. Но когда так много команд, непременно возникают ситуации, при которых в проект одной команды нужно встроить какую-то функциональность, разрабатываемую другой. И не просто встроить, но и потом поддерживать её работу, исправлять ошибки и внедрять новые фичи.
Возможности конкурентной обработки появляются в программе по разным причинам: некоторые связаны с расширением возможностей платформы, другие вводятся вместе с новым API, поступающим в стандартную библиотеку, некоторые связаны со сменой парадигмы и переменами в наших представлениях. В этой статье будет рассмотрено три способа решения одной и той же задачи, но с применением отличающихся инструментов и парадигм.
Эта статья является переводом материала «Mapper Contexts & Supercontexts: Decoupling Domain-Specific and Domain-Generic Bounded Contexts».
Вы создаете новую систему, и два члена вашей команды предлагают альтернативные архитектуры для отправки уведомлений. Какая из них правильная?
Первый разработчик предлагает модель push: ограниченный контекст должен дать указание Notifications отправить уведомление. Notifications должен просто подчиняться командам и отправлять указанные уведомления.
Второму разработчику не нравится модель push-уведомлений, и он предлагает решение на основе хореографии: когда ограниченные контексты создают события, Notifications должен подписаться на эти события и определять, когда отправлять уведомление.
Как бы вы спроектировали решение? Что еще более важно, как бы вы приняли это решение в команде? Как вы будете разрабатывать наиболее эффективную архитектуру, которая поддерживает краткосрочные цели и долгосрочное развитие?
Программа для создания файлов конфигурации. Часто встречается нужда держать конфигурационные файлы в порядке, и консистенции, распределять общие данные по разным типам файлам, у некоторых типов файлов нет возможности читать переменные окружения, или приходиться подстраиваться под каждый формат по отдельности. Для того чтобы не подстраиваться под каждый формат файла, можно использовать всю мощь python и держать все конфигурации в одном файле.
Если вы собрались плотно погрузиться в тему Doman Driven Design (DDD), о том как его применять, как использовать, для чего он нужен, и как с ним связаны Command and Query Responsibility Segregation (CQRS), Event Sourcing и другие термины из мира DDD то можно воспользоваться планом обучения, который последовательно погрузит вас в эти темы и поможет сориентироваться. Часть информации на русском, часть на английском языке, так как русскоязычных аналогов я не смог найти.
Как скрипты могут помочь при взаимодействии компонентов, типичных для IoT? С помощью языка Lua. Наш ведущий разработчик Леонид Садофьев рассказывает и показывает на примере своего демоприложения про использование Lua на проектах уровня бизнес-логики (BL). Его приложение разработано на С++ и применяется для умного дома, но может подойти и для приложений других типов. Всё важное под катом — передаём слово автору.
DDD — одна из моих основных рабочих методологий, я применяю её больше пяти лет. Хотя она довольна сложная, в том числе потому что это верхнеуровневый набор практик. DDD - это не фреймворк, когда нет опыта, его немного сложно применять. Тем не менее мы переводили на DDD работающие проекты, запускали с помощью нее новые — и у нас сложились некоторые практики и подходы.
Хотелось бы рассказать про те, что доказали у нас свою эффективность. Сегодня это будет стратегическое верхнеуровневое проектирование — о том, как разрабатывать программы с точки зрения моделей и требований. А в следующей части я расскажу про практики для работы с кодом и архитектурой, то есть более приближенные к разработке. Надеюсь, что вы сможете ими воспользоваться, а если вы еще не используете DDD у себя в проектах, то попробуете.
Прим. перев.: в этом материале, опубликованном прошлой весной в блоге Dropbox, инженеры компании рассказывают о том, какие проблемы были у их монолита, жившего аж с 2007 года, что они предприняли для их решения и какой результат это принесло.
Чтобы всегда радовать пользователей, сервис Dropbox должен быть надежным и отзывчивым. С самого начала нам, как компании, приходилось масштабироваться. Сегодня нашими услугами пользуются более 700 миллионов зарегистрированных пользователей со всех уголков планеты. В общей сложности они ежесекундно генерируют минимум 300 тыс. запросов. Увы, системы, отлично подходившие для стартапа, перестали справляться с возросшей нагрузкой. Возникла насущная потребность разработать новую модель для внутренних систем и, конечно, придумать способ перехода на нее без риска угробить основной продукт в процессе.
В этой статье мы расскажем, как и почему разработали и развернули Atlas — платформу, реализующую основные преимущества сервис-ориентированной архитектуры (SOA) и при этом минимизирующую типичные издержки, связанные с владением сервисом.
Давно читаю Хабр, но написать свою статью все не доходили руки. Точнее это больше ощущение, что выбранная тема может быть не интересна читателям, или у меня не получится красиво изложить мысли. Все же рискну рассказать про свой опыт разработки лабораторного оборудования с использованием подходов системного инжиниринга и концепции индустрия 4.0. Далее речь пойдет о моем проекте, который я решил сделать несколько лет назад.
