Есть большая система, которая приносит значительный доход компании и следовательно к качеству её кода предъявляются высокие требования.
Эта система, помимо всего прочего, использует курсы валют.
Логика получения курсов валют следующая. Клиентская сторона может получить их из кеша, из базы данных и из внешнего источника по http. В случае, если курса валют нет в кеше, надо проверить базу, и если там есть, положить в кеш. Если в базе нет -- проверить внешний источник и положить и в базу, и в кеш.
Надо реализовать эту логику. Предполагается, что она будет использоваться в куче разных мест.
Вероятно, в условии есть неточности, какое-то поведение не указано и тд. Нужно самостоятельно принять решение что делать в каждом таком случае и явно это пометить -- либо в комментарии, либо в файле типа readme. В этом же файле напишите, что бы вы сделали по-другому, будь у вас больше времени; какие у вас были соображения, как в целом должен выглядеть этот код, к чему вы вообще стремились.
Язык -- php 7.2.
Функционал отправки запросов, хранения данных в базе и в кеше реализовывать не надо, вместо них достаточно сделать заглушки. Вообще, ваша основная цель -- показать подход к проектированию, а не написать production-ready код. Не нужно реализовывать трудоёмкие технические детали. Вместо этого важнее как вы декомпозировали предметную область, как выглядят ваши классы, куда вы поместили логику.
Тесты vendor\bin\phpunit tests Покрытие тестами не полное, писал их больше удобства разработки. Пример main.php USD RUB Продумыванию инфраструктуры большого внимания не уделял, это сделано больше для возможности демонстрации работы. Слой бизнес-логики я отталкивался от терминологии, взятой с сайта (первой попавшейся ссылки) https://ru.fxfinance-pro.com/with-what-to-begin/slovar-terminov.php В задании требований по бизнес-логики как таковой не было, поэтому модели получились достаточно пустыми. классы: Currency - не было понятно существует ли ограниченный список валют, и какие должны использовать коды валют, поэтому я использовал 3х буквенное обозначение. В классе присутствует статический метод. Причиной такого решения является то, что я предпочитаю не класть логику в конструктор, а данный статический метод, является по сути именованным конструктором. CurrencyPair - класс может обладать большей функциональностью, Например, получение противоположной пары, следуя принципу yagni я не реализовывал неиспользуемые методы. CurrencyRate - сущность. Из задания не было ясно могут ли быть много разных курсов по одной валюте (за разное время, например). Поэтому, я решил для простоты не реализовывать суррогатный ключ, и использовать валютную пару как идентификатор. Метод getPair возвращающий объект, что может нарушить инкапсуляцию. Как вариант решения проблемы, клонировать объект, либо возвращать сразу же строковое представление. Слой инфраструктуры В моём решении нет конкретного класса, реализующего задачу. классы: Factory - создаёт объект, реализующий задачу из задания. Сам класс Factory особо не был продуман, я как я уже писал выше. CurrencyRateRepositoryInterface - наследуется от двух интерфейсов, данное разделение сделано в связи с тем, что в задании не упоминалось, что во внешний источник можно сохранять курс валюты. CurrencyRateFinderInterface - данный интерфейс подразумевает возврат null. Я посчитал такой интерфейс более удобным для тестирования, и интуитивно более понятным, хотя реализация класса CachingCurrencyRateFinder стала чуть больше. MemoryCurrencyRateRepository, DataBaseCurrencyRateRepository, RemoteServiceCurrencyRateFinder - Классы, предоставляющие доступ курсам валют из памяти, базы и внешнего источника. (если я правильно понял задачу под кэшем подразумевалось хранение в оперативной памяти) Заглушка, реализованная в виде агрегации фейкового репозитория. FakeCurrencyRateRepository - данный класс особо не продумывался, реализован для теста, как минимум мне не нравится интерфейс конструктора, требующий знание реализации. CachingCurrencyRateRepository - использует композицию Во избежание дублирования функционала CachingCurrencyRateFinder, сходу не нашёл как сделать это лучше. В данном коде можно немного запутаться из-за количества абстракций, Proxy классов. Так же тут нарушается CQRS.