При проектировании системы знание анти-паттернов и подвохов зачастую оказывается более полезным, чем знание самих паттернов. Отталкиваясь от этой идеи, я решил написать данную статью, чтобы рассказать о факторах, которые, на мой взгляд, приведут к созданию ненадёжных систем. В её основе лежит мой собственный опыт проектирования преимущественно распределённых корпоративных приложений. Будет здорово, если ниже вы поделитесь собственным опытом и полезными идеями по теме. Читать полностью »
Рубрика «архитектура по»
Как НЕ надо строить надежные системы
2022-11-13 в 10:00, admin, рубрики: ruvds_перевод, Анализ и проектирование систем, антипаттерны проектирования, архитектура по, Блог компании RUVDS.com, надежные системы, распределенные системыСистема типов — лучший друг программиста
2022-11-08 в 5:07, admin, рубрики: domain-driven design, архитектура по, информационная безопасность, Программирование, проектирование систем, системы типов, Совершенный кодЯ устал от одержимости примитивами и от чрезмерного использования примитивных типов для моделирования функциональной области.
Значение в string
не лучший тип для записи адреса электронной почты или страны проживания пользователя. Эти значения заслуживают гораздо более богатых и специализированных типов. Мне нужно, чтобы существовал тип данных EmailAddress
, который не может быть null. Мне нужна единая точка входа для создания нового объекта этого типа. Он должен валидироваться и нормализироваться перед возвратом нового значения. Мне нужно, чтобы этот тип данных имел полезные методы наподобие .Domain()
или .NonAliasValue()
, которые бы возвращали для введённого foo+bar@gmail.com
значения gmail.com
и foo@gmail.com
. Эта полезная функциональность должна быть встроена в эти типы. Это обеспечивает безопасность, помогает предотвращать баги и существенно повышает удобство поддержки.
Читать полностью »
Как мы меняли инфраструктуру облачного сервиса: эволюция от одной виртуальной машины к кластеру Kubernetes
2022-10-27 в 11:14, admin, рубрики: Help Desk Software, helpdesk, kubernetes, service desk, архитектура по, инфраструктура it-компании, системное администрирование, стартап, Управление продуктом, управление разработкойВот уже 7 лет мы развиваем Okdesk — облачную help desk систему для малого и среднего бизнеса.
В свое время мы начали с одной виртуальной машины у провайдера.
Постепенно сервис взрослел, менялись приоритеты, задачи и проблемы, с которыми мы сталкивались. Сегодня Okdesk живет уже на третьей версии инфраструктуры.
В этой заметке мы расскажем о том, как и почему эволюционировала архитектура Okdesk. А во второй части поста — почему мы перешли на Kubernetes, каких результатов это позволило добиться и что планируем делать дальше.
Мой краткий чек-лист по скилам системного аналитика
2022-06-06 в 14:32, admin, рубрики: css, javascript, sql, Анализ и проектирование систем, аналитик, архитектура, архитектура по, веб-технологии, диаграммы, интеграция сервисов, Карьера в IT-индустрии, софт-скиллыПривет! Меня зовут Валид Панин, хочу поделиться кратким чек-листом скилов аналитика. Расскажу какие харды и соф-скилы использую в своей работе с примерами, пояснениями и списком литературы и ресурсов, которые помогут подтянуть знания. Мне бы пригодился такой чек-лист как карта развития, если бы я сейчас начинал свой путь аналитиком.
Разработка (dev) и data science в enterprise — битва за ресурсы или эффективное сотрудничество?
2021-07-05 в 9:01, admin, рубрики: data science, devops, python, R, ruvds_статьи, Анализ и проектирование систем, архитектура по, Блог компании RUVDS.com, проектирование по, управление проектами, управление разработкой
В подавляющем большинстве случаев, когда речь заходит о «настоящей» разработке продукта или решения enterprise уровня, сразу появляются корпоративные архитекторы и глобальные архитектуры и шаблоны, высокоуровневые модели данных и концепты, попытки охватить всё и вся. Формируется шорт лист из языков и фреймворков, в рамках которых идет вся последующая разработка. Все «только на Java» или «только на C#» или… (впишите на свое усмотрение).
Несомненно, это является отражением предыдущего проектного опыта, лучших мировых практик, готовности подхватить новые запросы бизнеса и в общем случае такой подход оправдан. Но в каждом частном случае подобный глобализм на этапе взлета продукта, в тот момент, когда многое еще находится в состоянии неопределенности, может просто погрести под собой начинание и превратить проект в очередную неудачу. Можно ли что-то изменить, упростить и улучшить не теряя при этом в качестве?
Оказывается что это вполне возможно за счет объединения классической разработки ПО с инструментами и подходами data science (далее просто DS). Как этого можно достичь — разберем по шагам.
Материал является продолжением серии предыдущих публикаций.
Читать полностью »
Враг не пройдёт, или как помочь командам соблюдать стандарты разработки
2020-09-23 в 19:25, admin, рубрики: governance as a code, автоматизация, архитектура по, Блог компании Конференции Олега Бунина (Онтико), Программирование, тестирование, Тестирование веб-сервисовПодход governance as a code обеспечивает контроль соблюдения архитектурных принципов как в части конфигураций инфраструктуры, так и в части программного кода. Правила проверки каждого артефакта, будь то конфигурация k8s, список библиотек или даже описание сценария CI/CD, описаны специальным кодом проверки правил, имеют свой жизненный цикл, могут тестироваться и ничем не отличаются от обычного программного продукта.
Александр Токарев (Сбербанк) расскажет, как и что можно проверять в процессе разработки программного обеспечения, чтобы разрабатывать более безопасные и качественные приложения, и почему Сбербанк решил не использовать такие очевидные решения как SonarQube, а разработать собственное решение на базе Open Policy Agent без дополнительных пакетов над ним. Также Александр покажет, когда выбирать admission controller, когда использовать «чистый» Open Policy Agent, а когда можно обойтись без какого-либо контроля.
Александр поговорит о том, нужны ли стандарты, что такое язык Rego и что за крутой продукт Open Policy Agent, а также рассмотрит нетиповые кейсы его применения, как с ним работать, и как его использовать для контроля. Email Александра.
RabbitMQ. Часть 1. Introduction. Erlang, AMQP
2020-02-17 в 8:46, admin, рубрики: .net, C#, devops, Erlang/OTP, IIoT, Microservices, RabbitMQ, Анализ и проектирование систем, архитектура по, Системы обмена сообщениямиДобрый день! Хочу поделиться учебником-справочником знаний, которые мне удалось собрать по RabbitMQ
и сжать в короткие рекомендации и выводы.
Принцип единственной ответственности: глубокое погружение
2020-02-16 в 14:24, admin, рубрики: solid, srp, Анализ и проектирование систем, архитектура по, ооп, Программирование, Проектирование и рефакторингПро принцип единственной ответственности (The Single Responsibility Principle, SRP) уже было написано множество статей. В большинстве из них даётся лишь поверхностное его описание мало чем отличающееся от информации в википедии. А те немногие статьи что затрагивают ключевые особенности SRP делают это вскользь, не акцентируя на них внимания и не развивая тему дальше.
Эта статья — попытка дать более глубокое объяснение принципу единственной ответственности, а также показать как его всё таки можно применять на практике. Кому интересно — добро пожаловать под кат.Читать полностью »
Двойная бухгалтерская запись в реляционной БД
2019-12-18 в 10:56, admin, рубрики: архитектура по, базы данных, бухгалтерия, бухгалтерия и программисты, платежные системы, финансы, финансы в ITОт переводчика: в ходе моей работы в нигерийском финтехе пришлось мне создавать с нуля одну платежную систему. Я тогда ничего толком не понимал в вопросах бухгалтерии, в том как именно лучше хранить платежи и балансы. Но было подозрение, что примитивный вариант с одной циферкой баланса в аккаунте пользователя слишком прост чтобы быть правильным.
Разобраться и избежать кучи граблей в этом деле мне помогла данная статья. При этом информации по теме "как сделать свою платежную систему" довольно мало, а в учебниках по бухучету программисту сходу разобраться не так просто (и очень нудно). Надеюсь, этот материал окажется полезным тем, кто только собирается что-то такое делать.
Сразу извиняюсь за возможные неточности в русскоязычных финансовых терминах — я все-таки программист, а не бухгалтер, и с русской терминологией в этой сфере недостаточно знаком.
Введение
Многие компьютерные системы, использующие реляционные БД, хранят в них какую-то финансовую информацию о балансах и транзакциях. При этом при проектировании и разработке такой БД часто встает вопрос, а как именно хранить эту информацию. Обычно выбор стоит между дешевой "простой записью" и более сложной "двойной записью".
Лука Пачоли, автор самой старой (15 век) дошедшей до нас книги с описанием принципов двойной записи
В системе с "простой записью" числовые значения записываются только один раз. В системе с "двойной записью" каждое значение записывается дважды, как кредит (положительное значение) и как дебет (отрицательное значение). При этом есть набор правил, определяющих связь между этими значениями. Эти правила вам легко опишет любой опытный бухгалтер, хотя он может и не представлять, как именно они могут быть представлены в реляционной БД.
Основные правила таковы: