Рубрика «архитектура приложений» - 4

в 13:36, , рубрики: clean architecture, DDD, domain-driven design, Entity, patterns, ruby, ruby on rails, Screaming Architecture, Value Object, Анализ и проектирование систем, архитектура приложений, Программирование, Проектирование и рефакторинг, проектирование сайтов, проектирование систем, Роберт Мартин, эрик эванс

Введение

Итак, мы уже определились с областью применения, методологией и архитектурой. Перейдем от теории к практике, к написанию кода. Хотелось бы начать с шаблонов проектирования, которые описывают бизнес логику — Service и Interactor. Но прежде чем приступить к ним, изучим структурные паттерны — ValueObject и Entity. Разрабатывать мы будем на языке ruby. В дальнейших статьях разберем все паттерны, необходимые для разработки с использованием Вариативной архитектуры. Все наработки, являющиеся приложениями к данному циклу статей, соберем в отдельный фреймворк.

Blacjack & hockers

И мы уже подобрали подходящее название — LunaPark.
Текущие наработки выложенны на Github.
Разобрав все шаблоны, соберем один полноценный микросервис.

Читать полностью »

в 9:40, , рубрики: enterprise architecture, IT-стандарты, TOGAF, Анализ и проектирование систем, архитектор, архитектура приложений, как стать архитектором, Карьера в IT-индустрии, конференции, управление разработкой

5 сентября в Москве состоялся Круглый стол «Архитектор ИТ проекта» в ВШЭ. Организатор круглого стола, Максим Смирнов, ведет блог про архитектуру и канал на Facebook.

Я очень рада, что такие события проводятся. Стать классным архитектором было и остается моей мечтой. Мне очень долго было не понятно, как вообще попадают в архитекторы, как нужно развиваться и какие направления выбирать, чтобы они привели к архитектуре, и, я думаю, что такие вопросы возникают не только у меня. Замечательно, что есть сообщество, куда можно прийти и задать вопросы архитекторам.
На круглом столе было представлено 4 доклада по 15-20 минут, после чего были вопросы из аудитории и обсуждение.
Доклады были краткими и по сути, а обсуждение очень живое и развернутое.
Круглый стол «Архитектор ИТ проекта», сентябрь 2018 - 1
Читать полностью »

в 7:17, , рубрики: .net, C#, domain-driven design, архитектура, архитектура приложений, ооп, функциональное программирование

Как правило статьи, рассказывающие о проектировании типами, содержат примеры на функциональных языках — Haskell, F# и других. Может показаться, что эта концепция неприменима к объектно-ориентированным языкам, но это не так.

В этой статье я переведу примеры из статьи Скотта Власчина Проектирование типами: Как сделать некорректные состояния невыразимыми на идеоматичесий C#. Также я постараюсь показать, что этот подход применим не только в качестве эксперимента, но и в рабочем коде.

Читать полностью »

в 15:23, , рубрики: android, badoo, kotlin, mvi, mvicore, архитектура приложений, Блог компании Badoo, Программирование, разработка мобильных приложений, Разработка под android

Строим систему реактивных компонентов с помощью Kotlin - 1

Всем привет! Меня зовут Анатолий Варивончик, я Android-разработчик Badoo. Сегодня я поделюсь с вами переводом второй части статьи моего коллеги Zsolt Kocsi о реализации MVI, которую мы ежедневно используем в процессе разработки. Первая часть здесь.

Чего мы хотим и как мы это сделаем

В первой части статьи мы познакомились с Features, центральными элементами MVICore, которые можно переиспользовать. Они могут обладать максимально простой структурой и включать всего один Reducer, а могут стать полнофункциональным средством для управления асинхронными задачами, событиями и многим другим.

Каждая Feature отслеживаема — есть возможность подписаться на изменения её состояния и получать уведомления об этом. При этом Feature можно подписать на источник ввода. И в этом есть смысл, ведь с включением Rx в кодовую базу у нас и так появилось множество наблюдаемых объектов и подписок на самых разных уровнях.

Именно в связи с увеличением количества реактивных компонентов пришло время поразмышлять о том, что мы имеем и можно ли сделать систему ещё лучше.
Читать полностью »

в 13:44, , рубрики: clean architecture, domain-driven design, ruby, ruby on rails, Screaming Architecture, Анализ и проектирование систем, архитектура приложений, Программирование, Проектирование и рефакторинг, проектирование сайтов, проектирование систем, Роберт Мартин, эрик эванс

Введение

В рамках предыдущих статей мы выделили область применения подхода и рассмотрели основные методологические принципы Domain Driven Design.

В данной статье я хотел бы обозначить основные современные подходы к построению архитектуры корпоративных систем: Supple, Screaming, Clean и дать им свою четкую интерпретацию в виде полноценного готового решения.

WM

В дальнейшем рассмотрим каждый шаблон проектирования подробно: обозначим область применения, приведем примеры кода, выделим рекомендуемые практики. В итоге, напишем готовый микросервис.

Читать полностью »

в 13:01, , рубрики: android, badoo, kotlin, mvi, mvicore, архитектура приложений, Блог компании Badoo, Программирование, разработка мобильных приложений, Разработка под android

Современная MVI-архитектура на базе Kotlin. Часть 1 - 1

За последние два года Android-разработчики в Badoo прошли длинный тернистый путь от MVP к совершенно иному подходу к архитектуре приложений. Мы с ANublo хотим поделиться переводом статьи нашего коллеги Zsolt Kocsi, описывающую проблемы, с которыми мы столкнулись, и их решение.

Это первая из двух статей, посвящённых разработке современной MVI-архитектуры на Kotlin.
Читать полностью »

в 12:38, , рубрики: clean architecture, ejb, ERP-системы, legacy-код, Rule Engine, vendor lock, Анализ и проектирование систем, антипаттерны, архитектура по, архитектура приложений, архитектура системы, базы данных, командная работа, Проектирование и рефакторинг, разработка приложений, Совершенный код, управление проектами, чистая архитектура

За время своей карьеры я поработал с разными legacy-проектами, каждый из которых страдал от тех или иных изъянов.

Разумеется, часто главной проблемой было низкое качество программного обеспечения (отсутствие модульных тестов, отказ от использования принципов чистого кода…), но были также и трудности, чьим источником являлись архитектурные решения, принятые в начале работы над проектом или даже в период зарождения корпоративной системы. На мой взгляд, этот класс проблем является причиной наибольшей боли для многих проектов.

В сущности, улучшение кода — дело довольно простое, особенно сейчас, когда движение за мастерство разработки ПО (software craftsmanship) продвигает хорошие практики в командах. Однако изменение стержневых частей систем, ограничений, введенных в самом начале их жизненного цикла, является чрезвычайно сложной задачей.

Расскажу о нескольких типах встречавшихся мне архитектурных решений, которые могут стать реальным бременем для команд, занимающихся поддержкой подобных систем.

Читать полностью »

в 6:41, , рубрики: .net, domain-driven design, F#, архитектура, архитектура приложений, функциональное программирование

Представляю вашему вниманию перевод статьи Scott Wlaschin "Designing with types: Making illegal states unrepresentable".

В этой статье мы рассмотрим ключевое преимущество F# — возможность "сделать некорректные состояния невыразимыми" при помощи системы типов (фраза заимствована у Yaron Minsky).

Рассмотрим тип Contact. В результате проведённого рефакторинга он сильно упростился:

type Contact = 
    {
    Name: Name;
    EmailContactInfo: EmailContactInfo;
    PostalContactInfo: PostalContactInfo;
    }

Теперь предположим, что существует простое бизнес-правило: "Контакт должен содержать адрес электронной почты или почтовый адрес". Соответствует ли наш тип этому правилу?

Нет. Из правила следут, что контакт может содержать адрес электронной почты, но не иметь почтового адреса, или наоборот. Однако в текущем виде тип требует, чтобы были заполнены оба поля.

Кажется, ответ очевиден — сделать адреса необязательными, например, так:

type Contact = 
    {
    Name: PersonalName;
    EmailContactInfo: EmailContactInfo option;
    PostalContactInfo: PostalContactInfo option;
    }

Но теперь наш тип допускает слишком многое. В этой реализации можно создать контакт вообще без адреса, хотя правило требует, чтобы хотя бы один адрес был указан.

Как же решить эту задачу?

Читать полностью »

в 9:25, , рубрики: javascript, Анализ и проектирование систем, архитектура приложений, Блог компании JUG.ru Group, управление разработкой

Рассказ о том, что нужно учесть, чтобы выстроить качественную архитектуру вашего проекта. Как сделать его непотопляемым, а клиентов — довольными.

Ниже мы рассмотрим реальные примеры из жизни и попытаемся научиться на чужих ошибках. А попутно составим книгу полезных рекомендаций для solution-архитектора. Во всех историях — архитектурные задачи, которые начинаются с первичных требований клиента и сопровождаются дальнейшим разбором полетов.

Разработка архитектуры проекта, корабли и JavaScript - 1

В основе статьи — доклад Алексея Богачука (solution-архитектора компании EPAM) с конференции HolyJS 2018 Piter. Под катом — видео и расшифровка доклада.

Читать полностью »

в 9:58, , рубрики: api, javascript, Алгоритмы, архитектура приложений, интерфейсы, Разработка веб-сайтов, системная шина, слабые связи

Именованные события: программируем GUI

— Вы заметили, сэры, какие стоят погоды?
— Предсказанные, — сказал Роман.
— Именно, сэр Ойра-Ойра! Именно предсказанные!
(Понедельник начинается в субботу)

Именованные события: программируем GUI - 1

В настоящее время большинство сайтов представляют собой, по сути, обычную программу, которая обрабатывает те или иные действия пользователей. Для того, чтобы упрощать жизнь программистам, реализованы десятки фреймворков, помогающих решать те или иные задачи.

Если рассматривать программирование GUI или UI вообще, то в обобщенном случае UI представляет собой множество слабосвязанных задач в одном пакете.

Например, раздел "погода" на главной страничке поисковика является просто индикатором. Выбрав тему, мы можем увидеть дождик или солнышко на фоне (еще один вариант индикатора погоды). Нужно ли устанавливать взаимосвязь между разделом "погода" и темой? С точки зрения минимизации компьютерных расходов — безусловно. Не стоит перезапрашивать данные, полученные однажды. Однако, с точки зрения разработки, программирование слабосвязанных вещей может тянуть за собой настолько большие трудозатраты, что иногда проще отказаться от связанности и два раза запросить одни и те же данные.

О программировании слабосвязанных вещей в вебе мы и поговорим в этой статье.

Читать полностью »

1...345...10...13
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js