Принцип единственной ответственности (Single Responsibility Principle, SRP) — принцип ООП, обозначающий, что каждый объект должен иметь одну ответственность (назначение). Выполнение принципа приводит к более лучшей специализации классов.
Почему может происходить несоблюдение принципа:

• появление новой специфической функциональности, непредусмотренной изначально;
  
• накопление технического долга и длительное отсутствие рефакторинга;
  
• недостаточная информированность и представление разработчиками о том где и какие ресурсы приложение находятся => приводит к дублированию;
  
• слияние нескольких приложений в одно;

Виды SRP

• горизонтальное — разделение ответственности между объектами/классами одного слоя
  
• вертикальное — разделение ответственности между слоями
  
• инфраструктурное — разделение ответственности между системами ИТ-ландшафта

Последствия несоблюдения (примеры):

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

DDD

SPL
Инструкция
1. Сбор, структурирование, визуализирование и анализ информации о системе
Цель: наш мозг по прежнему является самой эффективной нейросетью, поэтому для качественного моделирования необходимо будет поместить всю логику в одну или несколько голов, для последующей обработки всей информации и генерации программных моделей. Для этого необходимо собрать информацию о процессах таким образом, чтобы визуально представлять в уме то как они работают.
Параллельно с таким исследованием можно формировать скелет новой единой документации, о методике разработке которой я ещё расскажу в другой статье.
Для выделения элементарных деталей программы прежде всего необходимо понимать абсолютно всю логику и функциональность, реализованную в проекте. Это необходимо, чтобы смоделировать работу всей программы в одной голове, абстрагироваться от реализации, найти общие черты различных реализованных алгоритмов и спроектировать такие универсальные «детали», которые можно было бы использовать во всех алгоритмах, таким образом избавившись от возможного дублирования кода.
Для анализа полезны любые источники — jira, документация, которая может быть в виде множества разросненных документов. Как правило редко в каком проекте есть исчерпывающая структурированная документация по всей системе и её фичам, поэтому основным и универсальным инструментом для исследования функционала будут:

• тестовая среда;
  
• хитроумные разнообразные тест-кейсы;
  
• общение с бизнес-пользователями и заказчиками;
  
• дотошные и коварные вопросы относительно функционала.

Предприимчивость и находчивость в этой части поможет собрать наибольший объём информации в кротчайшие сроки.
Следующий момент — это визуализация. Сейчас редко увидишь разработчиков, которые часто что-то рисовали, проектировали на бумаге, но в таком рисовании есть практический смысл, так как на этом строится визуализация, которая помогает разложить всё по полочкам, смоделировать и абстрагироваться. Записывать текстом можно, но его может оказаться очень много, а грамотно изображённая абстрактная схема позволяет без длительного чтения документации сразу понять что к чему и где. Только универсальных методик в части рисования не ждите. Я много искал, но возможно вам повезло больше и вы поделитесь в комментариях. А мне пришлось придумать что-то своё.
Таким образом подводя резюме первому шагу:

• настройтесь на сплошное изучение всей функциональности. Изучение позволит построить абстрактную модель в голове;
  
• развивайте фанатизм и любовь к предметной области. Фанатизм даст энергию и идеи для хитроумного подробного анализа логики и эмоции для запоминания;
  
• рисуйте на бумаге и в редакторах, схемы позволят разложить всё по полочкам.

2. Визуализация и моделирование бизнес-логики. Выделение деталей приложения (или выделение сущностей бизнес-логики)
Зная всю предметную область, можно выделить такие элементарные детали приложения, которые могут быть использованы в разных алгоритмах системы.
Мой проект относился к электронному юридически значимому документообороту между юридическими лицами через оператора.
Инструкция и рекомендации по построению схемы объектов бизнес-логики:
2.1. Выписать все объекты, над которыми в алгоритмах производятся операции. Не стесняемся использовать те имена, которые удобны — русские, английские…
2.2. Выписывая объекты бизнес-логики, ниже под их названием через точку выписываем поля, которые относятся к соответствующим объектам
* можно использовать разные языки (английский/русский) в одной схеме, так как они проще воспринимаются, но не стоит стесняться смешивать языки — всё ради удобства. На этапе моделирования это не так важно, так как на этапе реализации данные поля и названия в большей части будут переведены на английский и это ничему не навредит
** скорее всего будут такие алгоритмы, в которых не используются объекты, а используются и обрабатываются только значения каких-то отдельных полей, это ожидаемо от любителей фукнционального программирования. Стоит учитывать такие ситуации и при моделировании всё же группировать такие поля в объекты, к которым они относятся, запоминать такие функциональные алгоритмы и на будущее продумывать их таким образом, чтобы они использовали объекты, а не отдельные переменные с значением поля какого-либо объекта.

2.3. Выделив все используемые объекты и их поля на одном или нескольких листах, вы можете взглянуть на всё сверху и по общим полям понять, какие из сущностей можно аггрегировать в одну
Выполнение этого шага влияет на степень примерения SRP.
2.4. Выделите все действия, которые выполняются над соответствующими объектами
На рисунках действия от полей выделяются наличием фигурных скобок после названия действия, в которые так же можно добавлять какие-либо аргументы по необходимости, но всё это делается только условно, основная информация находится в уме.
После этого шага, первая картинка расширилась ещё и новыми сущностями.

2.5 Выделите классы-менеджеры (сервисы)
Класс-менеджер (сервис) — это такой класс, который выполняет действия над структурами данных, при этом сам он не используется в качестве структуры данных. Это может быть обёртка над каким-то источником данных — базой данных, облаком, api, файловой системой.
Так как в моём случае проект интеграционный и реализован на стыке различных других прикладных систем и сред — при выделении классов-менеджеров я руководствовался тем, где выполняются операции над выделенными объектами и тем где эти объекты хранятся.
Ландшафт нарисован в упрощённом варианте, выделены все связанные системы. Таким образом получились:

• операторы ЭДО
  
• файловая система
  
• база данных
  
• бизнес-логика самого приложения, в которую входят ранее выделенные сущности

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

• бОльшую архитектурную гибкость;
  
• уменьшение времени на доработку слоя БЛ;
  
• ускорение локализации дальнейших ошибок

На рисунке отмечена связь такой сущности как ПакетДокументов с определённой структурой файлов и папок, чтобы создать представление о некоторых нюансах и технических особенностях некоторых структур. До выделения сущности ПакетДокументов в бизнес-логику, работа происходила с обычным набором документов, но так как на уровне бизнес-модели такое понятие как ПакетДокументов существовало, то приходилось учитывать низкоуровневые особенности на слое бизнес-логики.

• взаимодействие между ERP разных компаний происходило на уровне пакетов
  
• по пакетам документов приходилось формировать отдельные статусы
  
• на уровне файловой системы формат пакетов отличался от формата других файлов

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

В результате этого шага:

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

CloudManager — используется для выполнения всех операций, с использованием облака операторов ЭДО и инкапсулирует всю логику взаимодействия с их API.
FSManager — используется при работе с файловой системой: особенности работы с различными форматами документов, структурой их хранения, абстракция от технических деталей реализации находится здесь, таким образом вызывая один метод SaveTo из слоя бизнес-логики, не надо задумываться об особенностях структур xml, папок, архивов, наборов фалов. Всё учтено в более низком слое. Так же в связи с тем, что существует бесчисленное количество форматов выгрузки xml, этот слой может расширяться поддержкой соответствующих форматов через дополнительные dll.
Всё это позволило выделить и построить базис, на основе которого будут собираться алгоритмы системы.
3. Выделение архитектурных слоёв
Под архитектурным слоем подразумевается определённый набор логики, то есть деталей приложения, которые позволяют реализовать пространство прикладных задач заданного уровня. Подробно это понятие разбирается в статье habr.com/ru/post/511252
Все прикладные задачи, реализуемые в приложении, можно разделить на уровни. Например сохранение настроек приложения лежит на более высоком уровне чем сохранение данных в файл. Выполнение действия подписания документа лежит на более высоком уровне, чем генерация ЭЦП. На разных уровнях используются свои структуры данных и менеджеры и подобное разделение может упростить работу разработчика. Допустим на ранее выделенном уровне бизнес-логики, описанной на шаге 2 — вообще нет непосредвенного обращения к крипто-провайдерам, всё было инкапсулирвоно в соответствующие классы, в которых используется своя более низкоупровневая логика.
В дополнение к ранее выделенной логике, для конечной реализации системы, были использованвы ещё несколько архитектурных слоёв:
1. DocumentSDK — слой работы с документами
Содержит в себе вышеописанный набор бизнес-логики, на базе которой строится работа вышесоящих слоёв
2. DocumentAutomatizationSDK — слой автоматизации работы с документами.
В этом слое реализованы алгоритмы роботов, выполняющих автоматизированную обработку документов:

• различные алгоритмы последовательности подписания документов,
  
• информирования, коррекции, обмен статусами между ERP и учётными системами
  
• выгрузки/загрузки документов в файлы и из файлов
  
• настройки работы роботов

Бизнес-логика слоя включала всего 2 класса:

• AutomatizationSettings — структура данных настроек робота
  
• AutomatizationWorker — активный класс, представляющий собой многопоточного робота, выполняющего алгоритмы в соответствии с настройками

3. DocumentAutomatizationService — слой сервиса
Это Windows-служба, которая

• предоставляет SOAP-API-интерфейс для оперативного управления работой роботов (запуск, мониторинг, изменение настроек);
  
• создаёт в себе среду исполнения множества роботов.

Бизнес-логика слоя включала в себя 1 класс, предоставляющий одновременно SOAP-API и инкапсулирующий в себе коллекцию роботов предыдущего слоя.
4. DocumentAutomatizationUI — слой пользовательского интерфейса управления службой
Это Winforms приложение, которая предоставляла возмоность редактирования пользовательских настроек робота, и управление роботами через WCF, подсоединяясь локально или к удалённому серверу, на котором была развернута служба.
Такое разделение по слоям, позволило дорабатывать разные слои независимо друг от друга и улучшило разделение кода на вертикальном уровне, тем самым увеличив применение принципа SRP.
В результате методики, на примере были получены архитектурные слои и их составляющие. По детальному описанию эти архитектурные слои можно реализовать на любом объекто-ориентированном языке, в определённые сроки, используя все преимущества многослойной архитектуры для разработки, например декомпозиция задач по уровню и распараллеливание разработки слоёв, параллельной разработке UI, слоя сервиса и логики.
===========
Источник:
habr.com
===========
Похожие новости:

• [Flask, Python, Проектирование и рефакторинг] Flask + Dependency Injector — руководство по применению dependency injection
  
• [CSS, HTML, JavaScript, Программирование, Разработка веб-сайтов] Как стать Front-End разработчиком
  
• [Python, Будущее здесь, ООП, Параллельное программирование] Мир без корутин. Итераторы-генераторы
  
• [Python, Машинное обучение, Программирование] 10 вещей, которые вы могли не знать о scikit-learn (перевод)
  
• [Dart, Flutter, Программирование, Разработка мобильных приложений] Flutter под капотом: Binding
  
• [Программирование, GitHub, Управление разработкой, Удалённая работа] «Конституция» для разработчиков: как страничка на GitHub помогает нам не ругаться уже год
  
• [Анализ и проектирование систем, Микросервисы, Проектирование и рефакторинг, Управление разработкой] От монолита к микросервисам: ускорили банковские релизы в 15 раз
  
• [Scala, Функциональное программирование] Fetch — библиотека для доступа к данным
  
• [C, Java, Python, Исследования и прогнозы в IT, Программирование] IEEE опубликовал новый рейтинг языков программирования
  
• [Agile, Локализация продуктов, Управление продуктом, Управление разработкой] Гибкая локализация: как применить agile к проекту по переводу

Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_programmirovanie (Программирование), #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_upravlenie_razrabotkoj (Управление разработкой), #_arhitektura_prilozhenij (архитектура приложений), #_programmirovanie (программирование), #_metodologija_razrabotki (методология разработки), #_protsess_razrabotki (процесс разработки), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_programmirovanie (
Программирование
), #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
), #_upravlenie_razrabotkoj (
Управление разработкой
)