Когда вы хотите дать пользователю возможность писать плагины для своего приложения, вы встаете перед выбором того, как предоставлять API. Под катом я покажу, почему худшим решением для этого будет изобретение собственного языка программирования и парсинг исходников, а также причем здесь мебель.
Рубрика «архитектура системы» - 2
Не создавайте собственный ЯП (DSL) для расширения функционала приложения
2019-01-18 в 22:13, admin, рубрики: архитектура системы, интерфейсы, Компиляторы, ненормальное программирование, Песочница, разработкаВсегда ли нужны Docker, микросервисы и реактивное программирование?
2019-01-16 в 15:58, admin, рубрики: docker, java, kubernetes, Анализ и проектирование систем, архитектура, архитектура по, архитектура системы, Блог компании DataArt, выбор технологии, микросервисы, реактивное программирование, управление проектамиАвтор: Денис Цыплаков, Solution Architect, DataArt
В DataArt я работаю по двум направлениям. В первом помогаю людям чинить системы, сломанные тем или иным образом и по самым разным причинам. Во втором помогаю проектировать новые системы так, чтобы они в будущем сломаны не были или, если говорить реалистичнее, чтобы сломать их было сложнее.
Если вы не делаете что-то принципиально новое, например, первый в мире интернет-поисковик или искусственный интеллект для управления запуском ядерных ракет, создать дизайн хорошей системы довольно просто. Достаточно учесть все требования, посмотреть на дизайн похожих систем и сделать примерно так же, не совершив при этом грубых ошибок. Звучит как чрезмерное упрощение вопроса, но давайте вспомним, что на дворе 2019 год, и «типовые рецепты» дизайна систем есть практически для всего. Бизнес может подкидывать сложные технические задачи — скажем, обработать миллион разнородных PDF-файлов и вынуть из них таблицы с данными о расходах — но вот архитектура систем редко отличается большой оригинальностью. Главное тут — не ошибиться с определением того, какую именно систему мы строим, и не промахнуться с выбором технологий.
В последнем пунктом регулярно возникают типичные ошибки, о некоторых из них я расскажу в статье.Читать полностью »
Миграция данных в кровавом энтерпрайзе: что анализировать, чтобы не завалить проект
2018-11-30 в 11:01, admin, рубрики: big data, cdi, data mining, sql, анализ данных, Анализ и проектирование систем, архитектура системы, Блог компании HFLabs, миграция данных, системная интеграцияТипичный проект системной интеграции для нас выглядит так: у заказчика вагон систем для учета клиентов, задача — собрать клиентские карточки в единую базу. И не только собрать, а еще очистить от дублей и мусора. Чтобы на выходе получились чистые, структурированные, полные карточки клиентов.
Для начинающих поясню, что миграция идет по такой схеме: источники → преобразование данных (отвечает ETL или шина) → приемник.
На одном проекте мы потеряли три месяца просто потому, что сторонняя команда интеграторов не изучала данные в системах-источниках. Самое обидное, что этого можно было избежать.
Читать полностью »
Архитектура как бремя
2018-11-02 в 12:38, admin, рубрики: clean architecture, ejb, ERP-системы, legacy-код, Rule Engine, vendor lock, Анализ и проектирование систем, антипаттерны, архитектура по, архитектура приложений, архитектура системы, базы данных, командная работа, Проектирование и рефакторинг, разработка приложений, Совершенный код, управление проектами, чистая архитектураЗа время своей карьеры я поработал с разными legacy-проектами, каждый из которых страдал от тех или иных изъянов.
Разумеется, часто главной проблемой было низкое качество программного обеспечения (отсутствие модульных тестов, отказ от использования принципов чистого кода…), но были также и трудности, чьим источником являлись архитектурные решения, принятые в начале работы над проектом или даже в период зарождения корпоративной системы. На мой взгляд, этот класс проблем является причиной наибольшей боли для многих проектов.
В сущности, улучшение кода — дело довольно простое, особенно сейчас, когда движение за мастерство разработки ПО (software craftsmanship) продвигает хорошие практики в командах. Однако изменение стержневых частей систем, ограничений, введенных в самом начале их жизненного цикла, является чрезвычайно сложной задачей.
Расскажу о нескольких типах встречавшихся мне архитектурных решений, которые могут стать реальным бременем для команд, занимающихся поддержкой подобных систем.
Перевод статьи Нила Форда «Микросервисы как эволюционная архитектура»
2018-09-26 в 7:21, admin, рубрики: devops, архитектура по, архитектура системы, Блог компании Luxoft, микросервисы, непрерывная поставка ПОМы подготовили перевод статьи Нила Форда, системного архитектора и идейного вдохновителя компании ThoughtWorks, которая занимается разработкой программных средств для автоматизации процессов тестирования и развертывания ПО.
Нил – признанный эксперт в области разработки программного обеспечения, работающий на стыке гибкого проектирования и системной архитектуры. Он является автором многочисленных статей, книг, десятков видео-презентаций, выступает с докладами на ведущих конференциях разработчиков. Его работы вы можете посмотреть на сайте nealford.com.
Читать полностью »
Простая объектная СУБД
2017-12-20 в 11:59, admin, рубрики: Алгоритмы, Анализ и проектирование систем, архитектура системы, базы данных, объектная СУБД, ПрограммированиеВ рамках одного проекта была поставлена задача долговременного хранения логически связанных объектов данных с обеспечением многопользовательского доступа к их содержимому. Возможны различные способы удовлетворения этой потребности средствами уже существующих систем управления данными. Тем не менее, был предпринят поиск простого и производительного решения, результаты которого и предлагаются к рассмотрению.
Читать полностью »
Разработка CPA-платформы для телеком-оператора
2017-08-22 в 7:20, admin, рубрики: cpa, Анализ и проектирование систем, архитектура системы, Блог компании Инфосистемы Джет
Под катом — рассказ о том, как мы реализовали модульную архитектуру CPA-платформы (Content Provider Access) для телеком-оператора на Fuse Fabric. Заодно объясним, почему приняли такое решение, а не стали использовать стандартный стек технологий J2EE для создания монолитного приложения.
Читать полностью »
Скажи «нет» монолитности: как мы делали CPA-платформу
2017-08-22 в 7:20, admin, рубрики: cpa, Анализ и проектирование систем, архитектура системы, Блог компании Инфосистемы Джет
Под катом — рассказ о том, как мы реализовали модульную архитектуру CPA-платформы (Content Provider Access) для телеком-оператора на Fuse Fabric. Заодно объясним, почему приняли такое решение, а не стали использовать стандартный стек технологий J2EE для создания монолитного приложения.
Читать полностью »
Apache Spark как ядро проекта. Часть 2. Streaming, и на что мы напоролись
2017-06-16 в 4:29, admin, рубрики: Apache Spark, big data, Hadoop, архитектура системыПривет коллеги.
Да, не прошло и три года с первой статьи, но проектная пучина отпустила только сейчас. Хочу с вами поделиться своими соображениями и проблемами касательно Spark streaming в связке с Kafka. Возможно среди вас есть люди с успешным опытом, поэтому буду рад пообщаться в комментариях.
Читать полностью »
Инфраструктура простой электронной подписи. Часть 4: Практические аспекты реализации
2017-02-01 в 3:48, admin, рубрики: IT-стандарты, Анализ и проектирование систем, архитектура системы, инфраструктура, проектирование, простая электронная подпись, Разработка под e-commerceВ части 1, части 2, части 3 были рассмотрены основные системы инфраструктуры ПЭП. В этой части будет рассмотрен порядок проектирования для практической реализации инфраструктуры. Сразу отмечу, что описание носит обобщенный характер, и не является ни туториалом, ни инструкцией, ни руководством. Как было отмечено в первой части, вся статья представляет собой только личное видение, основанное на практике внедрения ПЭП в информационные системы агентов, оказывающих сложные, многоэтапные технологические услуги. Цель внедрения ПЭП — расширить географию обслуживания за счет переноса в сеть Интернет документооборота при оказании услуги физическим лицам и минимизации необходимости личных визитов клиентов в офис компании. Для упрощения примера, не будем рассматривать большие компании со сложным документооборотом, а возьмем абстрактную компанию, оказывающей услуги домашней автоматизации. Документооборот услуги такой компании в минимальном варианте состоит из заявки на проектирование, договор с техническим заданием и акта выполненных работ.
Читать полностью »