Привет! Меня зовут Евгений, я Python-разработчик. Последние полтора года наша команда стала активно применять принципы Clean Architecture, уходя от классической модели MVC. И сегодня я расскажу о том, как мы к этому пришли, что нам это дает, и почему прямой перенос подходов из других ЯП не всегда является хорошим решением.
Рубрика «clean architecture» - 2
Clean Architecture глазами Python-разработчика
2020-03-27 в 10:12, admin, рубрики: architecture, clean architecture, clean code, design patterns, mvc, patterns, python, Блог компании Exness, Программирование, Проектирование и рефакторинг, Разработка веб-сайтовОртодоксальный Backend
2019-11-05 в 8:01, admin, рубрики: backend, clean architecture, dependency injection, domain-specific language, mvc, ruby, Программирование, Проектирование и рефакторингСовременный backend разнообразен, но всё-таки подчиняется некоторым негласным правилам. Многие из нас, кто разрабатывает серверные приложения, сталкивается с общепринятыми подходами, такими как Clean Architecture, SOLID, Persistence Ignorance, Dependency Injection и прочими. Многие из атрибутов серверной разработки настолько заезжены, что не вызывают никаких вопросов и используются бездумно. О некоторых много говорят, но никогда не используют. Смысл остальных же либо неправильно интерпретирован, либо перевран. Статья рассказывает о том, как построить простую, совершенно типичную, архитектуру backend, которая не только может без какого-либо ущерба следовать заветам известных теоретиков программирования, но и в некоторой степени может их усовершенствовать.
Читать полностью »
Бережная обработка ошибок в микросервисах
2019-07-08 в 5:05, admin, рубрики: clean architecture, Go, обработка ошибокВ статье показано, как в Go реализовать обработку ошибок и логирование по принципу "Сделал и забыл". Способ расчитан на микросервисы на Go, работающие в Docker-контейнере и построенные с соблюдением принципов Clean Architecture.
Поваренная книга разработчика: 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.
Сколько боли он нам принес.
Читать полностью »