Разработка ПО (архитект. ис)

DDD. Качественный скачок, необходимые предпосылки. Понятие гибкой архитектуры. Лучшие практики по построению гибкой архитектуры.

Качественный скачок - резкое улучшение модели предметной области за счет систематических небольших изменений.

Преобразование модели:

1.Текущая модель

•вызывает раздражение в мелочах

•не предлагает элегантного решения для новых требований

•сложно объяснить, что делает тот или иной код («узкие места»)

2.Мозговые штурмы:

•выявление неявных понятий

•моделирование неявных понятий

3.Возможно, будет много таких итераций с небольшими изменениями, но потом будет результат

Для постоянных улучшений нужно:

•Гибкая архитектура

•Изолированные модели

Гибкая архитектура.(с лучшими практиками – это примеры)

Информативные интерфейсы:

•Интерфейса достаточно, чтобы понять, что происходит если нужно смотреть реализацию – плохо!

•Имя должно описать назначение и результат, а не способ решения

•Имя должно быть взято из Единого языка

Функции без побочных эффектов:

Без побочных эффектов лучше:

•Код становится понятней и проще

•Функции проще пере использовать

•Можно построить модели с неизменяемые объектами

•что в свою очередь очень круто

Утверждения:

Описывают:

•Пред/пост условия операций

•Состояние инвариантов Агрегатов

Выражаются:

•В функциях

•Модульных тестах

Спецификации:

•Способ смоделировать ввести условия ограничений в модель

•Спецификация – предикат, которые проверяет – удовлетворяет объект некоторым значениям или нет

•В ООП реализуется с помощью Value Object, описывающих условия

•Конечные проверки спецификаций можно создавать в runtime

Изолированные классы:

Если это возможно, устраняйте любую зависимость, как только возможно.

Замкнутость операций Пример: матрица + матрица = матрица, не должен получаться объект другой природы

Декларативный стиль:

•Обычный стиль. Описываем, что нужно сделать, чтобы получить результат val result = List()

for (p : persons) {

if (p.age > 10) result += p

}

Pascal, C/C++, Basic, Java 7

•Декларативный стиль. Описываем, что нужно получить.

val result = persons.

filter(p => p.age > 10)

select * from persons where age > 10

SQL, функциональные языки и функциональные возможности в C#, Java 8, Scala

Все вместе:

DDD. Понятие контекста и ограниченное контекста. Методы организации разработки ограниченных контекстов. Карта контекстов.

Ограниченный контекст.

•Bounded Context

•В крупных проектах всегда есть несколько моделей предметных областей

•Ограниченные контекст определяет, в каком именно контексте используются семантика данной модели

Проблемы внутри контекста.

•Дублирующиеся понятия - В модели есть два элемента (класса), которые на самом деле обозначают одно и тоже понятие.

•Ложные родственники - Одно и тоже понятие по разному осмысленно и трактуется разными людьми в команде разработчиков

Карта контекста.

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

Решение

•проработать и ввести в Единый язык контексты для всех классов

•для каждого класса четко прописать, какому контексту он принадлежит

Взаимодействие межу контекстами:

•Как связаны контексты между собой?

•Как связаны похожие понятия в разных контекстах?

Общее ядро - понятия выносятся в общую зону для обоих контекстов.

Плюсы – снижаются затраты на интеграцию контекстов

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

Заказчики / поставщики

Вводятся два контекста – А и зависящий от него B (C, D, …).За A отвечает одна команда, команда контекста B ставит свои требования на реализацию.

Важно:

•потребности заказчика стоят на первом месте для поставщика

•A тщательно покрыт приемочными тестами, написанными командой B

Проблема заказчики/поставщики

Две группы (А и B) находятся на одном уровне подчинения. Группа B не имеет рычагов влияния на A, поэтому не может выступать полноценным Заказчиком.

Конформист

Вводятся два контекста – А и зависящий от него B (C, D, …). За A отвечает одна команда.

Команда контекста B адаптируется ко всем изменениям контекста A. Напоминает Общее ядро, но отличается тем, что общую часть правит только одна команда.

Предохранительный уровень.

Вводятся два контекста – А и зависящий от него B (C, D, …). За A отвечает одна команда. Команда контекста B вводит промежуточный слой между контекстами A и B.

Отдельное существование.

•Два независимых приложения

•Взаимосвязь с помощью интеграции

Плюс

полностью независимая разработка

Минус

интеграция может быть очень дорогой

Оценка ООП-дизайна приложения. Скофусированность/связность. Общие образцы разделения обязанностей. Понятие обязанности.

Связность - Насколько класс связан с другими классами.

Сфокусированность - Насколько класс сфокусирован на решение одной задачи.

Шаблон проектирования:

•Название

•Проблема

•Контекст

•Решение

GRASP - General Responsibility Assignment Software Patterns

Responsibility – обязанность. Контракт или обязательство объект

•Действия, выполняемые объектами класса

•Знания, которые поддерживают объекты

•Значительные решения, которые принимает объект и которые затрагивают другие объекты

Information Expert (информация эксперт)

Какой базовый принцип распределения обязанностей? Достаточно знает кто, назначай обязанности тому.

Creator

Кто должен создавать объекты класса A? Решение:

•Класс содержащий объекты A

•Класс записывает объекты A

•Класс активно использует A

•Класс владеет данными инициализации для объектов A

Low Coupling (Низкая сцепление)

Как уменьшить влияние вносимых изменений на другие объекты? Минимизировать степень связывания в процессе распределения обязанностей.

Controller

Кто должен отвечать за получение и координацию системных операций, поступающих от уровня пользователя?

•Класс представляет всю систему или важную подсистему

•Класс представляет собой сценарий некого прецедента, в рамках которой выполняет обработка этой системной операции

High Cohesion (Высокая сплоченность)

•Как обеспечивать высокую сфокусированность обязанность, их управляемость и ясность?

•Обеспечивать высокий уровень зацепления в процессе распределения обязанностей.

Polymorphism (полиморфизм)

•Как обрабатывать альтернативные варианты поведения на основе типа?

•Если обязанности класса могут изменяться, сокрой изменения в полиморфных операциях.

Pure Fabrication (Чистое изготовление)

•Как добиться чистоты дизайна, если все остальные подходы не работают?

•Присвоить группу обязанностей с высоким зацеплением специально созданному классу

Indirection (косвенность)

•Как обеспечить обязанности, чтобы обеспечить отсутствие прямого связывания?

•Присвоить обязанности промежуточному объекту для обеспечения связи между другими компонентами или службами.

Protected Variations (Защищенные вариации)

•Как спроектировать объекты, подсистему и систему, чтобы изменение этих элементов не оказывало нежелательного влияния на другие элементы?

•Идентифицировать точки возможного расширения системы и предоставить механизмы его расширения.

Принципы SOLID. Принципы DRY, KISS, YANGI

Масштаб

•Изначально принципы для ОО-дизайна

•Они настолько базовые, что можно масштабировать

Single Responsibility Principle

•Класс должен иметь одну и только одну обязанность/ответственность

•Существует лишь одна причина, приводящая к изменению класса

Open/Closed Principle

•Программные объекты (классы, модули, функции и т.д.) должны быть для расширения, но в то же время закрыты для модификации

•Изменение поведения модуля без изменения его исходных кодов.

Liskov substitution principle

•Все наследники должны соблюдать контракт предков

•Возможно расширение, но не замена/подмена

Dependency inversion principle

•Модули должны зависеть от абстракций, а не реализаций.

•Реализации также должны зависеть от абстракций

Interface segregation principle

•У классы выделяются интерфейсы, которые обслуживают разных клиентов

•Клиенты должны иметь представление об абстрактных базовых классах, имеющих связанные интерфейсы

Принцип DRY:

•Don’t Repeat Yourself (не повторятся не делать ctr+c, ctr+v) Принцип KISS:

•Keep calm and keep it simple stupid (чем проще тем лучше)

Принцип YAGNI:

•You Ain’t gonna need it (не делай лишнего)

TDD. BDD. Связь между ними.

TDD(test-driven development) – Разработка через тестирование техника разработки программного обеспечения.

Цикл разработки:

•сначала пишется тест, покрывающий желаемое изменение,

•пишется код, который позволит пройти тест.

Проблема – код нужно писать так, что бы его можно было тестировать.

Позволяет определится с архитектурой на этапе итераций.

Позволяет сразу определить какие функции нужны пользователям.

BDD(Behavior Driven Development) – разработка, основанная на функционировании. Ответвление от TDD. Фокус не на тестах а на поведении.

Цикл разработки:

•Заказчик описывает поведение по модели(Исходное состояние -> Событие->Проверка реакции)

•Пишется код

•Проверка соответствия поведению(тест прошел/ не прошел)

-----------------------------

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

И наконец, BDD

Можно сказать, третья версия отличается от предыдущих тем, что она

описывает поведение класса. Это достигается за счёт использования таких слов как «should» и «contain»: «мой класс должен вести себя так-то и так-то», «мой метод должен делать то-то и тото».

Так вот, идея BDD как раз и заключается в том, чтобы вместо слов «test» и «assert» использовать слова «spec» и «should». Да-да, разница всего лишь в словах, но именно это, по замыслу авторов

BDD, и делает спецификации удобочитаемыми, а написание тестов спецификаций до кода — естественным для человеческого мозга.