В статье показано, как в Go реализовать обработку ошибок и логирование по принципу "Сделал и забыл". Способ расчитан на микросервисы на Go, работающие в Docker-контейнере и построенные с соблюдением принципов Clean Architecture.
Рубрика «clean architecture» - 2
Бережная обработка ошибок в микросервисах
2019-07-08 в 5:05, admin, рубрики: clean architecture, Go, обработка ошибокПоваренная книга разработчика: DDD-рецепты (5-я часть, Процессы)
2019-06-04 в 13:48, admin, рубрики: clean architecture, domain-driven design, ruby, ruby on rails, Screaming Architecture, UML, uml-проектирование, use cases, Анализ и проектирование систем, архитектура приложений, Программирование, Проектирование и рефакторинг, проектирование сайтов, проектирование систем, Роберт Мартин, эрик эвансВведение
В рамках предыдущих статей мы описали: область применения, методологические основы, пример архитектуры и структуры. В данной статье, я хотел бы рассказать как описывать процессы, о принципах сбора требований, чем отличаются бизнес требования от функциональных, как перейти от требований — к коду. Рассказать о принципах применения Вариантов Использования (Use Case) и как они нам могут помочь. Разобрать на примерах варианты реализации шаблонов проектирования Interactor и Service Layer.
Примеры приведенные в статье даны с использованием нашего решения LunaPark, оно поможет вам с первыми шагами в описанных подходах.
Отделяем функциональные требования от бизнес требований.
Снова и снова случается так, что многие бизнес-идеи на самом деле не превращаются в конечный, намеченный продукт. Зачастую это происходит из-за неспособности понять разницу между бизнес-требованиями и функциональными требованиями, что в конечном итоге, приводит к несоответствующему сбору требований, ненужной документации, задержкам проекта и крупным проектным сбоям.
Или иногда мы сталкиваемся с ситуациями, в которых, хотя окончательное решение отвечает потребностям клиентов, но каким-то образом бизнес-цели не достигаются.
Поэтому крайне важно разделить бизнес-требования и функциональные требования, до того момента, как вы начнете их определять. Давайте разберем пример.
Как быстро попробовать CQRS-ES в Laravel или пишем банк на PHP
2019-04-15 в 23:33, admin, рубрики: clean architecture, laravel, php, sqrs/es, Программирование, Проектирование и рефакторинг, Разработка веб-сайтов
Недавно в подкасте "Цинковый прод" мы с товарищами обсуждали паттерн CQRS/ES и некоторые особенности её реализации в Elixir. Т.к. я в работе использую Laravel, грех было не покопаться в интернетах и не найти как же можно потягать этот подход в экосистеме данного фреймворка.
Всех приглашаю под кат, постарался максимально тезисно описать тему.
Поваренная книга разработчика: DDD-рецепты (4-я часть, Структуры)
2019-01-15 в 13:36, admin, рубрики: clean architecture, DDD, domain-driven design, Entity, patterns, ruby, ruby on rails, Screaming Architecture, Value Object, Анализ и проектирование систем, архитектура приложений, Программирование, Проектирование и рефакторинг, проектирование сайтов, проектирование систем, Роберт Мартин, эрик эвансВведение
Итак, мы уже определились с областью применения, методологией и архитектурой. Перейдем от теории к практике, к написанию кода. Хотелось бы начать с шаблонов проектирования, которые описывают бизнес логику — Service и Interactor. Но прежде чем приступить к ним, изучим структурные паттерны — ValueObject и Entity. Разрабатывать мы будем на языке ruby. В дальнейших статьях разберем все паттерны, необходимые для разработки с использованием Вариативной архитектуры. Все наработки, являющиеся приложениями к данному циклу статей, соберем в отдельный фреймворк.
И мы уже подобрали подходящее название — LunaPark.
Текущие наработки выложенны на Github.
Разобрав все шаблоны, соберем один полноценный микросервис.
Поваренная книга разработчика: DDD-рецепты (3-я часть, Архитектура приложения)
2018-11-13 в 13:44, admin, рубрики: clean architecture, domain-driven design, ruby, ruby on rails, Screaming Architecture, Анализ и проектирование систем, архитектура приложений, Программирование, Проектирование и рефакторинг, проектирование сайтов, проектирование систем, Роберт Мартин, эрик эвансВведение
В рамках предыдущих статей мы выделили область применения подхода и рассмотрели основные методологические принципы Domain Driven Design.
В данной статье я хотел бы обозначить основные современные подходы к построению архитектуры корпоративных систем: Supple, Screaming, Clean и дать им свою четкую интерпретацию в виде полноценного готового решения.
В дальнейшем рассмотрим каждый шаблон проектирования подробно: обозначим область применения, приведем примеры кода, выделим рекомендуемые практики. В итоге, напишем готовый микросервис.
Архитектура как бремя
2018-11-02 в 12:38, admin, рубрики: clean architecture, ejb, ERP-системы, legacy-код, Rule Engine, vendor lock, Анализ и проектирование систем, антипаттерны, архитектура по, архитектура приложений, архитектура системы, базы данных, командная работа, Проектирование и рефакторинг, разработка приложений, Совершенный код, управление проектами, чистая архитектураЗа время своей карьеры я поработал с разными legacy-проектами, каждый из которых страдал от тех или иных изъянов.
Разумеется, часто главной проблемой было низкое качество программного обеспечения (отсутствие модульных тестов, отказ от использования принципов чистого кода…), но были также и трудности, чьим источником являлись архитектурные решения, принятые в начале работы над проектом или даже в период зарождения корпоративной системы. На мой взгляд, этот класс проблем является причиной наибольшей боли для многих проектов.
В сущности, улучшение кода — дело довольно простое, особенно сейчас, когда движение за мастерство разработки ПО (software craftsmanship) продвигает хорошие практики в командах. Однако изменение стержневых частей систем, ограничений, введенных в самом начале их жизненного цикла, является чрезвычайно сложной задачей.
Расскажу о нескольких типах встречавшихся мне архитектурных решений, которые могут стать реальным бременем для команд, занимающихся поддержкой подобных систем.
DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе
2018-10-25 в 13:29, admin, рубрики: clean, clean architecture, cqrs, DDD, Hexagonal, onion, Screaming Architecture, Анализ и проектирование систем, архитектура приложения, Проектирование и рефакторинг
Эта статья — часть «Хроники архитектуры программного обеспечения», серии статей об архитектуре ПО. В них я пишу о том, что узнал об архитектуре программного обеспечения, что я думаю об этом и как использую знания. Содержание этой статьи может иметь больше смысла, если вы прочитаете предыдущие статьи в серии.
После окончания университета я начал работать учителем средней школы, но несколько лет назад уволился и пошёл в разработчики программного обеспечения на полный рабочий день.
С тех пор я всегда чувствовал, что мне нужно восстановить «потерянное» время и узнать как можно больше, как можно быстрее. Поэтому я стал немного увлекаться экспериментами, много читать и писать, уделяя особое внимание дизайну и архитектуре программного обеспечения. Вот почему я пишу эти статьи, чтобы помочь себе в обучении.
Читать полностью »
Cохранение состояний в android приложениях
2018-08-13 в 9:11, admin, рубрики: android, cache, clean architecture, dagger 2, onsavedinstancestate, state machine, разработка мобильных приложений, Разработка под androidСегодня я хотел поделиться с вами еще одним подходом сохранения состояния при разработке android приложений. Не для кого не секрет, что наше приложение в фоне может быть убито в любой момент и эта проблема становится все актуальнее с вводом агрессивного энергосбережения – привет Oreo. Также никто не отменял смену конфигурации на телефоне: ориентация, смена языка и т.д. И чтобы открыть приложение из бэкграунда и отобразить интерфейс в последнем состоянии нам нужно позаботиться о его сохранении. Ох уж этот onSaveInstanceState.
Сколько боли он нам принес.
Читать полностью »
Clean architecture в контексте кроссплатформенной разработки
2018-08-03 в 15:06, admin, рубрики: android, clean architecture, iOS, Разработка под android, разработка под iOSВсем привет. В последнее время довольно много статей написано на тему clean architecture. То есть чистой архитектуры, которая позволяет писать приложения, удобные в сопровождении и тестировании. Про саму чистую архитектуру вы можете прочитать в таких замечательных статьях как: Заблуждения Clean Architecture или Чистая архитектура, поэтому не вижу смысла повторять то, что уже написано.
Читать полностью »
Clean swift архитектура как альтернатива VIPER
2018-06-29 в 16:16, admin, рубрики: clean architecture, iOS, ios development, swift, swift 4, разработка под iOSВведение
На данный момент существует множество статей про VIPER — clean архитектуру, различные вариации которой в свое время стали популярны для iOS проектов. Если вы не знакомы с Viper, можете прочитать тут, тут или тут.
Я бы хотел поговорить об альтернативе VIPER — Clean Swift. Сlean Swift на первый взгляд похож на VIPER, однако отличия становятся видны после изучения принципа взаимодействия модулей. В VIPER основу взаимодействия составляет Presenter, он передает запросы пользователя Interactor’у для обработки и форматирует полученные от него назад данные для отображения на View Controller:
