The Clean Architecture.
Решение для создания многоразового, гибкого и тестируемого кода
What are the benefits of a software architecture?
Каковы преимущества архитектуры программного обеспечения?:
Создание хорошей архитектуры является ключом к созданию чистого, понятного и многоразового кода. Когда вы начинаете проект без определения хорошей архитектуры, ваше программное обеспечение, вероятно, станет беспорядочным в какой-то момент.
Когда вы создадите архитектуру, ваш код будет следовать шаблону, поэтому, когда кто-то попытается понять, что вы сделали, когда вам нужно будет что-то изменить или проделать рефакторинг, это будет намного проще и займет гораздо меньше времени.
Еще одно преимущество — это возможность писать хорошие тесты.
Тесты очень важны для того, чтобы иметь продолжительное, благонадежное и стабилизированное приложение. Они помогут вам выявить ошибки, прежде чем даже выпустить код. Тем не менее, попытка написать тесты для плохо написанного кода, например, очень связанного, является очень трудной (а иногда и невозможной) задачей. Когда вы пишете код под многоуровневой архитектурой, каждая вещь будет на своем месте, каждая задача будет разделена. Таким образом, Вы сможете протестировать свой код в полной изоляции.
Подводя итог, используя чистую архитектуру, ваш код станет:
- Многоразовым: хорошо написанный и организованный код можно использовать повторно (даже в других проектах).
- Гибким: рефакторинг и поддержка вашего кода станет проще и потребует мало усилий. Вам не нужно будет менять код везде, когда вы хотите заменить библиотеку на другую, например, потому что весь код, отвечающий за взаимодействие непосредственно с этой библиотекой, будет находиться на одном уровне.
- Чистым: код становится чистым и простым. Таким образом, если новый разработчик только что попал в вашу команду, он не будет иметь проблем, пытаясь понять код. А также, годы спустя, когда вы забудете, что вы сделали в этом коде, вы сможете легко понять его.
- Тестируемый: как было сказано ранее, с чистой архитектурой, тестирование кода будет более легкой задачей, потому что вы сможете обеспечить необходимую изоляцию.
- Менее зависимым от технологий, с которыми он был построен: замена базы данных на другую, изменение фреймворка, выбор другого механизма шаблонов, замена библиотек и т. д. не потребует от вас перезаписи всего кода. Эти изменения будут сделаны с небольшой корректировкой кода, что позволит выполнять эти изменения проще и быстрее.
Layered Architecture
Многоуровневая архитектура: Некоторые архитектуры, такие как чистая архитектура, луковая архитектура и шестиугольная архитектура, должны были обеспечить чистое, проверяемое, многоразовое, гибкое и менее технологически зависимое программное обеспечение путем разделения обязанностей и уменьшения сцепления. Эти архитектуры говорят об организации приложения на слоях, отделяя ядро приложения от других.
Изображение ниже представляет адаптацию моделей чистой архитектуры и луковой архитектуры; показывает организацию программного обеспечения на слоях и разделение ответственности.
На изображении выше круги представляют различные области программного обеспечения. Эти области взаимодействуют между собой в соответствии с правилом зависимости. Это правило определяет, что зависимость между кодом происходит только от самого внутреннего до самого внешнего слоя. Ни один слой не может иметь никаких знаний о реализации внутри внешнего слоя. Например, класс, определенный внутри слоя служб приложений, никогда не будет вызываться классом внутри слоя модели домена.
Domain model
Модель домена: В основе модели можно увидеть модель домена. Этот слой содержит только модели приложений или объекты. Объекты представляют бизнес-объекты приложения. Они не имеют доступа к другим слоям, они взаимодействуют только между собой, устанавливая связи с другими сущностями и объявляя их собственные атрибуты. Ниже показан пример сущности:
Domain Services
Службы домена: Сразу после слоя модели домена появляется доменная служба. Внутри этого уровня вы можете найти службы, которые используют доменные элементы модели, такие как фабрики, репозитории и интерфейсы.
Interfaces
Интерфейсы: они очень полезны для уменьшения связи между классами. Они определяют классы и их методы, не давая подробностей реализации. Таким образом, можно получить доступ к методу репозитория, например, не зная конкретной реализации класса, только ссылаясь на его интерфейс.
Ниже вы можете увидеть ICityRepository, интерфейс, определяющий функциональные возможности CityRepository.
Поскольку это интерфейс, никакая деталь реализации не дана. Таким образом, этот класс не предоставляет никаких сведений откуда берутся данные и как они создаются.
Только интерфейс репозитория будет доступен в случаях использования, не связывая класс с конкретной реализацией. Таким образом, если реализация репозитория изменится, вам не нужно будет изменять код во всех местах, которые используют этот репозиторий, потому что они не будут знать о реализации.
Repositories
Репозитории: они отвечают за извлечение и сохранение данных в базе. Используя их, классы вариантов использования не должны знать базу данных. Если вам когда-нибудь понадобится изменить решение для базы данных, вам нужно будет только изменить репозиторий, и никаких других изменений не потребуется делать в классах вариантов использования, которые используют методы для доступа к базе данных, так как параметры и возвращаемый тип данных остаются прежними.
Use Cases
Варианты использования: Этот слой содержит классы, определяющие специфику бизнес-правил для приложения. Они инкапсулируют и реализуют примеры использования системы. Этот слой управляет потоком данных на уровне домена и за его пределами и предоставляет сведения для приложения. Этот слой не будет затронут из-за изменений базы данных, пользовательского интерфейса, модулей шаблонов и т. д. Варианты использования изменятся только при изменении требований бизнес-правил системы.
Вместе со слоями домена слой вариантов использования создает ядро приложения. Эти слои отвечают за бизнес-правила, и все остальные уровни приложения зависят от них. В соответствии с чистой архитектурой, они являются приложением, и все остальное только расширение или клиент, который взаимодействует с реальным приложением.
Application Services
Службы приложения: Сразу после уровней домена и вариантов использования находятся службы приложений. Этот уровень отвечает за реализацию приложения. В традиционной системе MVC это был бы контроллер. Он будет отвечать за разрешение маршрутов, ответы и маршрутизацию запросов к действию конкретного контроллера, к которому они должны получить доступ. На этом уровне также выполняются другие службы приложений, такие как аутентификация, перевод и возврат данных . Домен и варианты использования не должны зависеть от этого уровня, поэтому, если, например, изменение структуры становится необходимым, это может быть сделано с минимальными усилиями.
User Interface
Пользовательский интерфейс: Одним из самых внешних слоев является пользовательский интерфейс. От него не должен зависеть ни один из самых внутренних слоев, но в то же время он зависит от всех. Пользовательский интерфейс зависит от уровня служб приложений, потому что он будет направлять запрос, проходя через варианты использования и уровни службы домена, пока он не достигнет модели домена. Разделение этого слоя означает, например, изменение механизмов шаблонов, платформ javascript и т. д., без необходимости внесения каких-либо изменений в ядро приложения.
Infrastructure
Инфраструктура: Уровень инфраструктуры определяет источник данных в приложении. Это позволяет сохранять и извлекать данные из источника данных, который может быть реляционной базой данных, API или любым другим источником.
Уровень инфраструктуры зависит от домена, если он является доменом, который предоставляет контракт, описывающий, как должна вести себя инфраструктура. Этот контракт сделан с помощью интерфейсов. Уровень службы приложений также зависит от вариантов использования, поскольку варианты использования будут взаимодействовать с другими службами домена посредством внедрения зависимостей.
External Libraries
Внешняя библиотека: Внешние библиотеки могут ускорить процесс разработки, повторно используя существующий код и позволяя вам сосредоточиться на важных функциях вашего приложения. И это очень круто!
Однако представьте, что произойдет, если вы начнете использовать множество библиотек, не разрабатывая архитектуру их использования. Вы просто начинаете вызывать эти библиотеки внутри ваших классов вокруг вашего кода. Теперь представьте, что те библиотеки, которые вы использовали, устарели или ваши потребности изменились, и теперь вам нужно заменить эти библиотеки другими, в соответствии с этими новыми требованиями. Как выбудете менять эти библиотеки? Вам придется изменить все классы, которые их используют! И шансы что-то сломать, будут высоки!
Adapters
Адаптеры: если вам нужно использовать внешние библиотеки, лучший способ избежать неприятные ситуации в связи - использовать адаптеры.
Они предоставят вам интерфейс для взаимодействия с этими библиотеками, не давая вам зависеть от них.
Для этого, во-первых, вам нужно будет создать интерфейс, как один из примеров ниже:
Теперь, вместо вызова самой внешней библиотеки, вы сможете вызвать этот интерфейс и не беспокоиться о том, как будет выполнена реализация.
И последнее, но не менее важное, вам придется создать адаптер. Он будет инкапсулировать внешнюю библиотеку и будет следить за ее работой.
Теперь, если вам нужно изменить библиотеку, вам нужно будет только изменить адаптер и, убедившись, что он все еще получает и возвращает то, что должен был получать и возвращать раньше, вы можете спокойно двигаться дальше.
Кроме того, если ваше приложение использует автоматизированные тесты, вам не нужно будет беспокоиться о тестировании внешних библиотек, ваши тесты будут отвечать только за то, чтобы знать, используются ли библиотеки соответственно, как они должны быть.
Test
Тест: Этот слой будет содержать все ваши тесты. В нем вы найдете реализацию модульных тестов, тестов функций, интеграционных тестов и всевозможных тестов, которые у вас могут быть. Никакой другой сервис или слой не должны зависеть от него, однако, он может зависеть от всех других внутренних слоев.
Wrapping up
Подводя итог: Создание хорошей архитектуры для вашего проекта — это большой шаг к успеху. Многоуровневые архитектуры, такие как чистая архитектура, превосходны для организации кода. Если вы хотите разработать чистый, тестируемый, многоразовый, гибкий и менее связанный код, вы должны определенно рассмотреть возможность их использования.
В этом посте я обсуждал чистую архитектуру для достижения этих характеристик. Я также говорил о некоторых слоях и представил чистый и организованный способ архитектор ваших приложений.
Если вы смотрите на них в первый раз или если вы новичок в архитектуре программного обеспечения, это может выглядеть подавляющим. Тем не менее, уверяю вас, после того, как вы изучите эти принципы и поймете роль каждого элемента, процесс разработки будет еще проще и поддержание этого приложения будет незатруднительным.
Я надеюсь, что этот пост дал вам понимание и и желание, чтобы начать строить лучшую архитектуру! И если вы хотите углубиться в архитектуру кода, вы можете найти большое количество полезной информации здесь:
Не стесняйтесь комментировать и делиться своими предложениями, опытом и мыслями по чистой архитектуре.
Translated: medium
Help us with your claps :)
