Slides for happydev 2013 (architecture)
JavaScript CSS
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
css
js
lib
plugin
test
.gitignore
.travis.yml
Gruntfile.js
LICENSE
README.md
clean-arch.html
context-map.jpg
deduction.jpg
deming.png
index.html
kaizen.png
niquola.jpg
package.json
sample.html
semat.png
use-case.png

README.md

Clean Architecture

My slides for happydev.2013

Что такое архитектура?

Software Architecture as a Set of Architectural Design Decisions

A. Jansen & J. Bosch

Решение это часто компромис

Умные люди знают, любое решение имеет обратную сторону (tradeoff)

У монеты две стороны; У палки два конца

  • CAP & Basically Available, Soft-state, Eventually consistent
  • Простота и Гибкость
  • Модульность и монолитность

Это сокрыто в природе вещей

Три закона диалектики

Закон единства и борьбы противоположностей

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

Разница только в том насколько осознано вы выбираете

Иногда полезно использовать негативное определение (ибо в порыве вдохновения о темной стороне часто забывают).

Хорошее решение уменьшает кол-во негативных последствий

Основная задача дизайна уменьшить боль, а не увеличить количество ништяков! Нет хорошей или плохой архитектуры - она может быть обоснованной или нет!

Тренинг «Проектирование обоснованной архитектуры», Евгений Кривошеев

LEAN manufacturing (производственные концепции и практики Toyota)

Идет по лесу циклоп. Тут навстречу ему медведь метётся. Циклоп:

  • Стоять! Кто такой?
  • Медведь.
  • Та-а-ак-сь. Так и запишем: МЕДВЕДЬ. Завтра придешь к моей пещере, я тебя буду есть. Вопросы есть?
  • Нету...- поник медведь. Циклоп идет дальше. Тут навстречу - волк:
  • Стоять! Кто такой?
  • Волк.
  • Та-а-ак-сь. Так и запишем: ВОЛК. Завтра придешь к моей пещере, я тебя буду есть. Вопросы есть?
  • Нету...- поник волк. Циклоп идет дальше. Тут навстречу - заяц:
  • Стоять! Кто такой?
  • Заяц.
  • Та-а-ак-сь. Так и запишем: ЗАЯЦ. Завтра придешь к моей пещере, я тебя буду есть. Вопросы есть?
  • А можно не приходить?
  • Та-а-ак-сь. Зайца вычеркиваем.

Делая выбор, порой забывают, что есть еще одна опция - "Отложить этот выбор"

good architecture maximizes the number of decisions not made

Robert Martin (Uncle Bob)

Архитектура не висит в воздухе

Мы часть бизнес-механизма, производящего ПО (see SEMAT)

Свое подтверждение архитектура должна выводить из требований Требования из бизнес модели

semat

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

System Thinking

Экспоненциальный рост сложности - взаимодействие частей!

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

Design is taking things apart and then compose

Rich Hickey

DDD: Bounded Contexts & Aggregates

Как правильно разрезать быка? По суставчикам

[Domain Driven Design] (http://en.wikipedia.org/wiki/Domain-driven_design) by Eric Evans

  • Bounded Contexts
  • Aggregates
  • Entities & Value Objects

context map

Сложная предметная область

Если ваш контекст - сложная предметная область или неизвестность, то как быть

Что значит сложная?

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

Здесь вас поджидает ловушка - ПРЕЖДЕВРЕММЕННОЕ МОДЕЛИРОВАНИЕ!

Преждевременная оптимизация — корень всех зол

Д. Кнут «Structured Programming with go to Statements»

Behaviour Driven

С наружи важнее то как система себя ведет (внешние требования) нежели то как она устроена (внутренние требования)

Top-Down & Bottom-Up

Опять диалектика - Induction & Deduction

Вообще есть два подхода.

  • Придумать модель и вывести приложение (скорость и магия, но большой риск)
  • Вывести из приложения модель (низкий риск ошибки, но время и ресурсы)

Надо осознанно и своевременно пользоваться обоими по очередно.

Notes about RoR :)

Как мы описываем систему - Use Case

Use Case -последовательность взаимодействий с системой направленная на достижение цели

Почему бы не отобразить Use Case прямо в код?

Отображаем Use Case в код

iam.tap do |s|
  confirmation_key = nil

  s.listen :sign_up do |ev|
    confirmation_key = ev.confirmation_key
  end

  s.sign_up!(email, password)
  s.confirm!(confirmation_key)

  session_key = s.sign_in!(email, password)
  s.session_active?(session_key).should be_true

  s.sign_out!(session_key)
end

Итак: Use Case Driven

  • Use Case - собираем и приоретизируем требования, проверяем их не противоричивость
  • Prototype - делаем самую-самую дешевую реализацию и уточняем требование и наше понимание
  • Specification - пишем автоматическую спецификацию
  • Implementation - пишем работающую реализацию и заходим на второй цикл проверки
  • Refactoring to deeper insight - когда находим правильную модель - рефакторим с тестами

Закон Конвея & Кайдзен