Внедрение сценариев использования стало проще

Этот пост является частью серии статей "Реализация сценария использования", в которых я делюсь своими знаниями по проектированию, разработке и реализации сценариев использования.

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

Проблема

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

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

Сосредоточьтесь на языке, на котором ваши заинтересованные стороны (бизнес-эксперты) говорят о своих проблемах.

Мой совет - забыть о том, как данные будут сохраняться в базе данных, схеме базы данных для ваших сущностей, их взаимосвязи, а также о том, как в конечном итоге будет выполнен вариант использования (HTTP, обмен сообщениями, консольная команда и т. Д. ). Вместо этого сосредоточьтесь на поведении. Сосредоточьтесь на языке, на котором ваши заинтересованные стороны (бизнес-эксперты) говорят о своих проблемах. Посмотрите на инварианты, которые они явно или неявно описывают. Все эти концепции определяют то, что ваш бизнес хочет, чтобы вы реализовали, и те, которые будут способствовать созданию вашего продукта независимо от настойчивости или механизма коммуникации, который вы можете выбрать в конечном итоге. Хороший архитектор - это тот, кто оставляет выбор деталей инфраструктуры до конца и вместо этого сосредотачивается на политиках (бизнес-логике).

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

Оглавление

  1. Реализация варианта использования (I) - Введение
  2. Реализация варианта использования (II) - Шаблон команды
  3. Реализация варианта использования (III) - Командная шина
  4. Реализация варианта использования (IV) - Доменные события (I)
  5. Реализация варианта использования (IV) - Доменные события (II)
  6. Реализация варианта использования (V) - стиль тестирования« дано, когда-то »
  7. Продолжение следует…

Структура серии

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

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

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

Основываясь на этом простом примере, я поделюсь своим опытом применения различных шаблонов, принципов и практик, таких как:

  • Разработка через тестирование как механизм, заставляющий нас сосредоточиться в первую очередь на поведении, а не на технических деталях, а также на источнике документации для нашего кода.
  • Шаблон команд для явного представления вариантов использования вашего приложения.
  • События домена для явного представления фактов, происходящих в вашей системе.
  • CQRS как способ горизонтального масштабирования вашего приложения и упрощения реализации и поддержки операций чтения и записи вашего приложения.
  • Источники событий, помещая события в качестве источника истины, чтобы у вас был подробный журнал изменений каждого действия, когда-либо сделанного вашим приложением.
  • Шаблоны SAGA и Process Manager для управления распределенными транзакциями, когда ваше приложение состоит из различных микросервисов, которые взаимодействуют друг с другом.
  • Domain Driven Design как набор инструментов, который объясняет большинство концепций, которые мы будем рассматривать в этой серии.

В каждом посте я буду добавлять объясненные шаблоны и код в репозиторий приложения для обзора кода, которое вы можете найти здесь. Кроме того, я буду создавать новую версию в репозитории github для каждой публикации, которую я публикую, поэтому в самой публикации будет ссылка на конкретную версию, которая позволит вам увидеть, как выглядел код в тот момент (вы можете увидеть все выпуски "здесь"). Таким образом, вы сможете увидеть окончательный дизайн приложения, а также эволюцию кода, пока я буду объяснять и вводить новые концепции.

Я постараюсь объяснить большинство концепций своими словами, не вдаваясь в технические детали. В сообщениях будет ссылка на другие источники документации, где вы можете найти более подробные и точные объяснения всех концепций. Целевая аудитория - это люди, которые изучают и привыкают к предметно-ориентированному дизайну, гексагональной архитектуре, принципам SOLID, архитектуре, управляемой событиями и т. Д. Итак, я намерен провести вас через все эти концепции, используя примеры и с точки зрения высокого уровня, как там уже являются отличными книгами и документацией, чтобы вы могли глубоко изучить любую из этих тем.

Для реализации и объяснения приложения выбранным языком будет PHP, единственная причина в том, что это тот язык, который я использую последние 4 года, поэтому мне удобнее его использовать. В любом случае, одни и те же шаблоны уже объяснены на многих разных языках, поэтому у вас не должно возникнуть проблем с поиском аналогичного способа сделать то же самое на предпочитаемом вами языке. Кроме того, если вы понимаете концепцию, но сомневаетесь в деталях реализации, вы всегда можете опубликовать их.

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