+

На php

+

в смысле согласен? а чо не сделал? :D

Ну я ж не пишу идеальный код с момента создания.

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

fun someMethod(inputArguments): SomeResult
{
val request = requestBuilder.buildRequestForSomething(inputDataIfNeeded)
val yourObject = responseParser.parseResponse(client.requestForSomething(request))

object.doSome()
object.doAnother()
}

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


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

$fields['COMPANY_ID'] = $bxCompany->first()['ID'];
$fields['CONTACT_ID'] = $bxContact->first()['ID'];

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

помни про:
валидный объект, если он отражает бизнес логику, он валидный после конструктора
общие вещи которые можно оставить за пределами какого-то объекта, лучше там и оставить, вместо того что бы прокидывать дополнительно тьму ненужных данных, прокидывай то, без чего твой класс не будет работать и только
вся валидация и тд остается на границе http ( в твоем случае контроллер, ну мб form request если знаешь)
вся обработка ошибок и тд остается в клиенте которых ходит в интеграцию

можешь сделать интерфейс вроде

client.doSome(request)
.getOrElse { return SomeError }

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

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

Ну вот даже не для идеального кода проще будет дергать обертку над апи простейшую.
чето типа $client->get('/foo/bar?c=1'); где внутри будет инкапуслирована вся логика запросов к апи, ключи секрентные, базовые урлы и необходимые заголовки.

Очень полезно, спасибо. Как переделаю. Пришлю новый вариант

забыл добавить, не всегда объекты домена получаются универсальными, это окей, на границах других контекстов не грешно их преобразовывать в нужный тебе формат
например есть User
есть Location[]

такими обычно занимаются мапперы, если у тебя не получается в реляционную теорию и тд

делаешь

val userLocations = someMapper.map(user, locations)

сущность, это некая единица чего-то
со временем она может превращаться в что-то комплексное

val userPreferedStore = userLocations.find { it.store = "geo" }
val cart = Checkout(Item, userPreferedStore)
cart.submit()
ну крч суть ты понял

угу, вроде понятно.

Есть смысл использовать фреймворк (тот же symfony) или лучше писать с нуля?

есть.

но зависит от проекта.

после этого начнешь активно юзать D из солида, полезут косяки ларки. Скажешь ну его нахер этот кусок говна, пойду на симфу переписывать 🤣

онлайн чат)
чисто для портфолио

лару бери

там для чата решение готовое есть

да у меня там чот маршрутизация не ворк

Как называется? работает на соккетах или на лонгполлинге?