Pull to refresh

Drink&Talk: приглашаем разработчиков C# на встречу

Reading time 1 min
Views 605
Positive Technologies corporate blog Programming *.NET *C# *IT career

Где собираются лучшие C# разработчики? На нашем митапе, который пройдет 2 февраля в Нижнем Новгороде! Встречаемся в 18:30 в баре Talk&More🍺.

На следующий день, 3 февраля, участники митапа посетят наш офис, где смогут пройти собеседование с руководителями разработки и стать частью команды!

Зарегистрироваться
Rating 0
Comments 0

Введение в CQRS + Event Sourcing: Часть 1. Основы

Reading time 8 min
Views 174K
Website development *.NET *Designing and refactoring *
В первый раз я услышал о CQRS, когда устроился на новую работу. В компании, в которой работаю и по сей день, мне сразу сказали что на проекте, над которым я буду работать используется CQRS, Event Sourcing, и MongoDB в качестве базы данных. Из этого всего я слышал только о MongoDB. Попытавшись вникнуть в CQRS, я не сразу понял все тонкости данного подхода, но почему-то мне понравилась идея разделения модели взаимодействия с данными на две — read и write. Возможно потому что она как-то перекликалась с парадигмой программирования “разделение обязанностей”, возможно потому что была очень в духе DDD.

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

Сразу хочу уточнить что я работал только со связкой CQRS + Event Sourcing, и никогда не пробовал просто CQRS, так как мне кажется что без Event Sourcing он теряет очень много бенефитов. В качестве CQRS фреймворка я буду использовать наш корпоративный Paralect.Domain. Он чем-то лучше других, чем то хуже. В любом случае советую вам ознакомиться и с остальными. Я здесь упомяну только несколько фреймворков для .NET. Наиболее популярные это NCQRS, Lokad CQRS, SimpleCQRS. Так же можете посмотреть на Event Store Джонатана Оливера с поддержкой огромного количества различных баз данных.

Начнем с CQRS


Что же такое CQRS?
CQRS расшифровывается как Command Query Responsibility Segregation (разделение ответственности на команды и запросы). Это паттерн проектирования, о котором я впервые услышал от Грега Янга (Greg Young). В его основе лежит простое понятие, что вы можете использовать разные модели для обновления и чтения информации. Однако это простое понятие ведет к серьёзным последствиям в проектировании информационных систем. (с) Мартин Фаулер
Читать дальше →
Total votes 22: ↑20 and ↓2 +18
Comments 15

Введение в CQRS + Event Sourcing: Часть 2

Reading time 8 min
Views 47K
Website development *.NET *Designing and refactoring *
В прошлой статье я начал с основ CQRS + Event Sourcing. В этот раз я предлагаю продолжить и более подробно посмотреть на ES.

В примере который я выкладывал с моей прошлой статьей магия Event Sourcing’а была скрыта за абстракцией IRepository и двумя методами IRepository.Save() и IRepository.GetById<>().
Для того чтобы поподробнее разобраться что происходит я решил рассказать о процессе сохранения и загрузки агрегата из Event Store на примере проекта Lokad IDDD Sample от Рината Абдулина. У него в аппликейшен сервисах идет прямое обращение к Event Store, без дополнительных абстракций, поэтому все выглядит очень наглядно. Application Service — это аналог CommandHandler, но который обрабатывает все комманды одного агрегата. Такой подход очень удобный и мы тоже на него в одном проекте перешли.
Читать дальше →
Total votes 14: ↑13 and ↓1 +12
Comments 39

Incoding Rapid Development Framework ( part 2 CQRS )

Reading time 7 min
Views 6.4K
.NET *ASP *C# *
Tutorial
image

Пред история


Моя предыдущая статья была знакомством с Incoding Framework, которое начиналось с IML (наша флагманская фича ). IML подтолкнул нас развить проект больше, чем набор утилит ( такого добра полно в любой команде разработчиков ) используемых в проектах компании, но это не значит, что другие компоненты не прорабатываются, а напротив «полируются» с не меньшей детализацией и это я попробую Вам доказать.

Серебренная пуля ?


Раньше я всегда был сторонником того, что у каждого решения есть свои минусы и плюсы, но CQRS на мой взгляд превосходит N-Layer, а также не имеет «противопоказаний» или «побочных эффектов», что делает его кандидатом на первый патрон в обойму, но обо всем по порядку.

Кто-то не слышал про CQRS?


Для тех, кто уже использует CQRS, первые разделы могут быть не интересны, поэтому прежде чем поставить ярлык «велосипед», предлагаю ознакомиться с разделом killing feature, который может Вас убедить в обратном. Тем же, кто использует N-Layer архитектуру, стоит задуматься о переходе на CQRS и чтобы подкрепить свое предложение я опишу наш путь к CQRS
Читать дальше →
Total votes 1: ↑1 and ↓0 +1
Comments 7

Рентабельный код

Reading time 12 min
Views 65K
Website development *Designing and refactoring *
Tutorial


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

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.

Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.

До Agile и XP вся ответственность за работу с рисками ложилась на менеджеров. В гибких методологиях разработчики гораздо больше вовлечены в процесс и делят ответственность с менеджерами. Однако, принципы XP и Agile – больше методологические, чем технологические. Я думаю, что с рисками эффективнее работать комплексно на всех уровнях, в том числе на самом низком уровне, т.е. во время проектирования и написания кода.

Почему об этом следует думать разработчику, если есть менеджер?
  1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
  2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
  3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.
Читать дальше →
Total votes 76: ↑68 and ↓8 +60
Comments 26

Рентабельный код 2: крадущийся DDD, затаившийся CQRS

Reading time 20 min
Views 49K
Website development *.NET *Designing and refactoring *
Tutorial

Трем программистам предложили пересечь поле, и дойти до дома на другой стороне. Программист-новичок посмотрел на короткую дистанцию и сказал, «Это не далеко! Это займет у меня десять минут». Опытный программист посмотрел на поле, немного подумал, и сказал: «Я мог бы добраться туда за день». Новичок посмотрел на него с удивлением. Гуру-программист посмотрел на поле и сказал. «Кажется минут десять, но я думаю пятнадцати будет достаточно». Опытный программист рассмеялся.

Программист-новичок двинулся в путь, но в течение нескольких мгновений, начали взрываться мины, оставляя после себя большие ямы. От взрывов он отлетал назад, и ему приходилась начинать сначала снова и снова. У него ушло два дня чтобы достичь цели. К тому же он весь трясся и был ранен, когда пришел.

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

Гуру программист пустился в путь, и пошел прямо через поле. Целеустремленно и прямо. Он достиг цели всего за десять минут.
«Как тебе это удалось?» — спросили двое других — «Как ты умудрился не зацепить ни одной мины?»
«Легко» — ответил он. «Я не закладывал мины на своем пути».

Как ни прискорбно, придется признать – мы сами закладываем себе мины. В первой части я подробно разобрал основные риски в разработке ПО и описал технологические и методологические способы ослабления этих рисков. За прошедший год я получил множество комментариев, основной смысл которых сводился к следующему: «все круто, но с чего начать и как все это будет выглядеть в реальном мире». Действительно, первый текст носит скорее теоретический характер и представляет собой каталог ссылок. В этой статье я постараюсь привести как можно больше примеров.
Читать дальше →
Total votes 30: ↑27 and ↓3 +24
Comments 19

Incoding Framework — Get started

Reading time 23 min
Views 10K
.NET *ASP *C# *
Tutorial
IncFramework-logo

disclaimer: данная статья является пошаговым руководством, которое поможет ознакомиться с основными возможностями Incoding Framework. Результатом следования данному руководству будет покрытое юнит-тестами приложение, реализующее работу с БД (CRUD + data filters). О Incoding framework ранее уже были статьи на habrahabr, но в них раскрываются отдельные части инструмента.

Часть 0. Введение


Для начала приведем краткое описание фреймворкаIncoding Framework состоит из трех пакетов: Incoding framework – back-end проекта, Incoding Meta Language – front-end проекта и Incoding tests helpers – юнит-тесты для back-end’а. Эти пакеты устанавливаются независимо друг от друга, что позволяет интегрировать фреймворк в проект частями: Вы можете подключить только клиентскую или только серверную часть (тесты очень сильно связаны с серверной частью, поэтому их можно позиционировать как дополнение).
В проектах, написанных на Incoding Framework, в качестве серверной архитектуры используется CQRS. В качестве основного инструмента построения клиентской части используется Incoding Meta Language. В целом Incoding Framework покрывает весь цикл разработки приложения.
Типичный solution, созданный с помощью Incoding Framework, имеет 3 проекта:

  1. Domain (class library) отвечает за бизнес-логику и работу с базой данных.
  2. UI (ASP.NET MVC project) клиентская часть, основанная на ASP.NET MVC.
  3. UnitTests (class library — юнит-тесты для Domain.

Читать дальше →
Total votes 18: ↑13 and ↓5 +8
Comments 43

Гексагональная архитектура

Reading time 31 min
Views 139K
PHP *Symfony *Laravel *
Translation
На недавнем Laracon NYC я читал доклад о гексагональной архитектуре. Несмотря на то, что я получил позитивную реакцию слушателей, мне кажется, что остались люди, которые хотели бы получить чуть более полное представление о том, что это такое. Разумеется, с примерами. Это моя попытка расширить тот доклад.

  1. Видео с доклада
  2. Слайды


По моему мнению, данная архитектура является отличным примером того, как должна строиться структура приложения. Более того, когда я писал свои проекты на Laravel, я, даже не зная этого, частенько использовал идеи, заложенные в основе гексагональной архитектуры.



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



Гексагональная архитектура, ни в коем случае не новый подход к разработке с применением фреймворков. Напротив, это всего лишь обобщение «лучших практик» — практик новых и старых. Я обернул эти слова в кавычки, чтобы люди не воспринимали их совсем буквально. Лучшие практики, которые работают для меня, могут не работать для вас — все зависит от задачи и преследуемых целей.



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


Читать дальше →
Total votes 20: ↑16 and ↓4 +12
Comments 16

Типы CQRS

Reading time 5 min
Views 27K
Programming *.NET *C# *ООP *
CQRS — довольно хорошо изученный паттерн. Часто можно слышать, что вы либо следуете CQRS, либо нет, имея ввиду что это что-то вроде бинарного выбора. В этой статье я бы хотел показать, что существует спектр вариаций этого понятия, а также как разные типы CQRS могут выглядеть на практике.
Читать дальше →
Total votes 19: ↑16 and ↓3 +13
Comments 21

CQRS, UI, основаный на заданиях, Источники событий… ах

Reading time 4 min
Views 14K
Programming *Designing and refactoring *
Translation
Ремарка от меня. Подобрать терминологию было непросто, поэтому готов в процессе редактировать перевод, чтобы улучшить понимание текста.

Многие заблуждаются в отношении того, что собой представляет CQRS. Они рассматривают CQRS как архитектуру, хотя он таковым не является. CQRS – это простой шаблон, имеющий много архитектурных возможностей. CQRS не является конечной согласованностью, событийностью, или обменом сообщениями, это не модель для чтения и записи, и не использование источников событий. Я попробую несколькими абзацами описать, что такое CQRS, а потом рассмотрю, какое отношение он имеет к другим шаблонам.
Читать дальше →
Total votes 14: ↑12 and ↓2 +10
Comments 8

Ленивый event sourcing или как жить сегодняшним днем

Reading time 3 min
Views 13K
Open source *Programming *Java *Designing and refactoring *
Перевод статьи опубликованной на Eventsourcing Publications. Статья описывает некоторые из идей примененных в проекте Eventsourcing.

Если вы читали статью Фаулера или подобные источники на тему event sourcing, у вас в мозгу могла остаться вот приблизительно такая картинка:

image

Общая идея такого подхода заключается в том, что пользователь (или любая другая внешняя система) генерирует команды, мы их обрабатываем, складывая полученные события в event store и обновляя «состояние мира» в базе данных, данные из которой запрашивает пользователь.

Этот подход выглядит просто и красиво. У нас есть достаточно данных чтобы «переигрывать» события, у нас есть откуда запрашивать данные о состоянии мира и мы можем использовать проверенные временем базы данных. С другой стороны, я обратил внимание что я хотел немного другого от концепции event sourcing. Мне хотелось избежать предугадывания будущего и эта модель как-то не очень подходила, потому что мне приходилось записывать обновленное состояние в мою базу данных «для чтения».

Читать дальше →
Total votes 13: ↑10 and ↓3 +7
Comments 35

Как мы попробовали DDD, CQRS и Event Sourcing и какие выводы сделали

Reading time 9 min
Views 71K
Website development *Programming *System Analysis and Design *.NET *C# *
Вот уже около трех лет я использую в работе принципы Spec By Example, Domain Driven Design и CQRS. За это время накопился опыт практического применения этих практик на платформе .NET. В статье я хочу поделиться нашим опытом и выводами, которые могут быть полезными командам, желающим использовать эти подходы в разработке.

Факты, цифры, код
Total votes 39: ↑39 and ↓0 +39
Comments 45

Марсоход, Введение

Reading time 4 min
Views 12K
Website development *PHP *Programming *TDD *Algorithms *
Tutorial
Translation


Добро пожаловать в серию статьей «Марсоход», где мы будем использовать следующие практики:

  • Monolithic Repositories — MonoRepo (Монолитные репозитории)
  • Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
  • Event Sourcing — ES (События как источник)
  • Test Driven Development — TDD (Разработка через тестирование)

В этой вводной статье мы просто обозначим спецификации нашего марсохода.

Примечание. Этот пример является адаптированной для нужд серии статей версией упражнения, представленного на Dallas Hack Club, который сейчас, к сожалению, лежит.


Но сначала, давайте кратко пройдемся по упомянутым выше терминам.
Читать дальше →
Total votes 20: ↑19 and ↓1 +18
Comments 11

Марсоход, Инициализация

Reading time 4 min
Views 5.4K
Website development *PHP *Programming *TDD *Web services testing *
Tutorial
Translation


В этой серии статей мы строим программное обеспечение марсохода в соответствии со следующими спецификациями. Это позволит применить нам на практике следующие подходы:

  • Monolithic Repositories — MonoRepo (Монолитные репозитории)
  • Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
  • Event Sourcing — ES (События как источник)
  • Test Driven Development — TDD (Разработка через тестирование)


Cначала нам нужно инициализировать наш проект.
Читать дальше →
Total votes 12: ↑9 and ↓3 +6
Comments 2

Марсоход, Посадка

Reading time 5 min
Views 5.8K
Website development *PHP *Programming *TDD *Web services testing *
Tutorial
Translation


В этой серии статей мы строим программное обеспечение марсохода в соответствии со следующими спецификациями. Это позволит применить нам на практике следующие подходы:


  • Monolithic Repositories — MonoRepo (Монолитные репозитории)
  • Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
  • Event Sourcing — ES (События как источник)
  • Test Driven Development — TDD (Разработка через тестирование)


Ранее мы создали пакет навигации, теперь можно приступать к разработке первого варианта использования:


Марсоход должен будет сначала приземлиться в заданном положении. Положение состоит из координат (X и Y, являющихся целыми числами) и ориентации (строковое значение north, east, west или south).
Читать дальше →
Total votes 14: ↑12 and ↓2 +10
Comments 0

Марсоход, Координаты посадки

Reading time 4 min
Views 4.2K
Website development *PHP *Programming *TDD *Web services testing *
Tutorial
Translation


В этой серии статей мы строим программное обеспечение марсохода в соответствии со следующими спецификациями. Это позволит применить нам на практике следующие подходы:


  • Monolithic Repositories — MonoRepo (Монолитные репозитории)
  • Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
  • Event Sourcing — ES (События как источник)
  • Test Driven Development — TDD (Разработка через тестирование)

Оглавление

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


Марсоход должен будет сначала приземлиться в заданном положении. Положение состоит из координат (X и Y, являющихся целыми числами) и ориентации (строковое значение north, east, west или south).

Сегодня мы будем рефакторить LandRover:

Читать дальше →
Total votes 13: ↑10 and ↓3 +7
Comments 1

Отчет и материалы конференции MageConf 2016

Reading time 1 min
Views 4.7K
Conferences
image
10 Декабря 2016 года в Киеве прошла конференция MageConf 2016. Тематика конференции — весь стек технологий, используемых в Magento. Конференция прошла в 2 потока: Backend и Frontend.

Под катом вы сможете найти видео всех докладов презентованных на конференции:
Читать дальше →
Total votes 14: ↑14 and ↓0 +14
Comments 2

Моя модернизация Byndyusoft.Infrastructure | DDD + CQRS + WebApi

Reading time 5 min
Views 6.4K
.NET *C# *
Sandbox
Всем привет! Я часто ищу в просторах интернета «идеальную архитектуру» и несколько месяцев назад наткнулся на интересную реализацию и хотел бы поделится немного дополнив его.

Ссылка на реализацию

Немного модернизации и я получил вполне универсальный рабочий шаблон.

Для всех, кто не знаком с DDD можно начать с wiki.

В конце мы получим связку с DDD + CQRS + Entity Framework + OData + WebApi + Log4Net + Castle Windsor + Kendo UI.
Читать дальше →
Total votes 20: ↑16 and ↓4 +12
Comments 6

Основы CQRS

Reading time 11 min
Views 68K
SimbirSoft corporate blog Programming *.NET *Designing and refactoring *
Данная статья основана на материале из различных статей по CQRS, а также проектов, где применялся такой подход.

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

Поэтому при разработке зачастую можно наблюдать одни и те же проблемы в организации кода и архитектуры, а также в их усложнении. При неправильном подходе к проектированию рано или поздно может наступить момент, когда код становится настолько сложным и запутанным, что каждое внесение изменений требует все больше времени и ресурсов.
Читать дальше →
Total votes 16: ↑16 and ↓0 +16
Comments 88