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

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

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

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

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

Но сначала, давайте кратко пройдемся по упомянутым выше терминам.

Monolithic Repositories — MonoRepo (Монолитные репозитории)

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

Этот подход дает нам следующие преимущества:

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

Однако, он также приносит и следующие недостатки:

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

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

Примечание. Вот несколько ссылок для дополнительного знакомства с монолитными репозиториями:

• Advantages of a monolithic version control
• On Monolithic Repositories

Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)

CQRS — это о разделении логики «записи» и «чтения», и ее можно применять на многих уровнях, например:

• read-only микросервисы и микросервисы на запись
• конечные точки/задачи только для чтения или только для записи
• разделение ваших моделей на две (опять же, только для чтения и только для записи)

Важно отметить, что CQRS также может быть частично применен в рамках проекта: используйте его только когда это действительно имеет смысл.

Примечание. Вот несколько ссылок о CQRS:

• Command / Query Responsibility Segregation
• CQRS
• Adding the R to CQS: some storage options
• Clarified CQRS
• Functional foundation for CQRS / ES
• Messaging Flavours
• Avoiding the Mud
• Do not mistake DDD for CQRS. Yeah but where to start?
• CQRS/ES
• Fighting Bottlenecks with CQRS

Event Sourcing — ES (События как источник)

С ES каждое значимое действие записывается как «событие». Отслеживание таких событий обеспечивает следующие преимущества:

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

Как и с CQRS, важно отметить, что ES также может быть применен _частично_ в проекте: используйте его только когда есть необходимость.

ES часто ассоциируется с CQRS, но они могут использоваться и по отдельности.

Примечание. вот несколько ссылок об ES:

• Using logs to build a solid data infrastructure or: why dual writes are a bad idea
• Event Sourcing
• Practical Event Sourcing
• CQRS/ES
• Fighting Bottlenecks with CQRS
• Functional foundation for CQRS / ES
• Meeting the Broadway team — talking DDD, CQRS and event sourcing

Test Driven Development — TDD (Разработка через тестирование)

TDD можно свести к трем шагам:

1. создать тест
2. написать достаточно кода, чтобы пройти тест (быстрого и грязного, или просто «заставить работать»)
3. рефакторинг кода (создание чистого, «правильно работающего»)

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

Такой подход легко позволяет иметь высокое покрытие кода (хотя, строго говоря, все равно нужно проверять все возможные пути кода, не только успешные).

Примечание. вот несколько ссылок о TDD:

• Straw man TDD
• Coverage!!!
• The Failures of “Intro to TDD”
• TDD, avoid testing implementation details
• Monogamous TDD
• When TDD doesn’t work
• Does TDD really lead to good design?
• TDD is dead, long live testing
• What TDD is and is not
• TDD, where it all went wrong
• TDD and Complexity
• Giving up on TDD

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

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

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

После всего этого он сможет ездить с помощью инструкций, таких как move_forward (сохраняя ориентацию, но двигаясь по оси x или y) или turn_left/turn_right (сохраняя те же координаты, но изменяя ориентацию).

Время от времени, он будет сообщать текущее местоположение (опять же x и y координаты и ориентацию).

Например, ровер может приземлился на 23, 42, north и затем получить инструкции двигаться вперед дважды, затем налево, а затем снова вперед. Когда будут запрошены координаты, он сообщит 22, 44, west.

Декомпозируем задачу

Из приведенных выше спецификаций, можно выявить как минимум три варианта использования:

1. Посадка ровера на Марс
2. Вождение
3. Запрос местоположения

Что дальше

В следующей статье мы создадим проект и его первый пакет: navigation.

Примечание. Мы будем использовать:

• PHP 7
• Composer
• git
• phpspec и расширение SpecGen

ссылка на оригинал статьи https://habrahabr.ru/post/314536/