давай uml рисуй

Не умею :)

Это что касается данных. Лишние подробности опустил.

Есть система оплаты, которая, если брать только оплату товаров и услуг состоит из двух классов. Один отвечает за саму оплату, её способ (создать Payment, подтвердить платёж). Второй вызывается исключительно предыдущим и отвечает за цель, назначение платежа (в данном случае тупо задать заказу статус "оплачен", либо откатить обратно). Оно тоже как-бы готово и всё ништяк.

Но это пока платёж представлял из себя просто сумму в рублях, которую надо оплатить или списать с лицевого счёта.

Как вдруг появилась логика, которой надо сунуть свои щупальца во всё сразу.

У юзера появились подписки, второй личный счёт (не в рублях, а "в курьерах").

Подписка влияет на скидку, на активность обоих лицевых счетов (и на их пополнение за одно). Т.е. если активна подписка, то за доставку пытаемся снять "балл" со счёта бесплатных доставок (при этом заказ может требовать 0, 1 или 2 доставки). Если, скажем. требуется 2 доставки, а на счету доставок всего одна, то надо будет снять одну с этого счёта, а за вторую рублями. Если подписка не активна, то и счета личные неактивны, так что всё в рублях. При неактивной подписке доставка оплачивается в рублях, но цена зависит от общей суммы заказа. Далее рубли по тому-же принципу списываются сколько комжно с личевого счёта, а остальное уже идёт к оплате через платёж.

При этом платёж атомарен. Т.е. списывать рубли/баллы с личных счетов нужно в тот же момент, когда подтверждается платёж. Он подтверждается или сразу (если там сумма к оплате 0 и всё с личных счетов) или платёжным сервисом или администратором.

Выходит так, что после создания заказа нужно всё это дело подсчитать (на самом деле при любом изменении заказа пересчитывать и выводить). И потом сделать собственно платёж.

В плане данных есть следующие модели (в смысле AR, тупо пассивные структуры): Orders OrderGoods Goods PaymentItems Payments User

а ну ты уже не получишь красивое ООП)

В плане данных получается, что платёж должен иметь три суммы вместо одной: Сумма в рублях к оплате; Сумма в рублях для списания с баланса; Сумма в баллах на бесплатную доставку;

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

А в плане логики нужно где-то эту лабуду считать перед созданием платежа.

и у меня у юзера было 3 баланса

balance, unconfirmedBalance, garantedBalance

и норм было

Либо ещё варант, что платёж должен включать помимо назначений платежа ещё и "источники" платежей, а сам никаких сумм не иметь.

Даже не знаю как эту хрень назвать, которая считает такой вот итог по заказу. Плюс нужно платёж на основе этого итога создавать.

Либо ещё варант, что платёж должен включать помимо назначений платежа ещё и "источники" платежей, а сам никаких сумм не иметь.

я чето не понимаю, тебе надо тупо лог транзакций хранить?

ладно, дай почитаю что ты написал целиком)

а ну ты уже не получишь красивое ООП)

Почему? С самим разбиением что-то не так или ты за то, чтобы логику и данные в одних и те-же классах держать?

Почему? С самим разбиением что-то не так или ты за то, чтобы логику и данные в одних и те-же классах держать?

ну это типа инкапсуляция и все такое. Ну там есть варианты как сделать можно с AR красиво, но это уже будет не AR а Row Data Gateway

*лан, пропускаю филосовствования почему я перешел от того, чтобы логику с данными смешивать* Меня более всего беспокоит собственно блин вышеописанная логика-осьминог

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

Выходит нужен ещё один компонент, который будет хм... Во-первых считать это всё. Во-вторых создавать соответвтующий платёж. (Или же не надо это смешивать...)

Как бы эту хрень на два метода назвать

Фактически это такая оферта в коде. Включающая в себя цены, скидки, условия, работу с лицемым счётом, всякими баллами.

Фактически это такая оферта в коде. Включающая в себя цены, скидки, условия, работу с лицемым счётом, всякими баллами.

тебе тип рассказать как разбить это все на модули/контексты?

тут короч все упирается в то что тебе надо - максимально гибкая система с проблемами с производительностью

или же "решить задачу"

*лан, пропускаю филосовствования почему я перешел от того, чтобы логику с данными смешивать* Меня более всего беспокоит собственно блин вышеописанная логика-осьминог

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

Ну значит у меня прикольная процедуррщина, при этом не лишенная полиморфизма, да и инкапсуляции

Ну значит у меня прикольная процедуррщина, при этом не лишенная полиморфизма, да и инкапсуляции

расскажи подробнее как у тебя достигается инкапсуляция

ну то есть если ты выстроил слой доменной модели поверх модели данных - вполне верю

Ну значит у меня прикольная процедуррщина, при этом не лишенная полиморфизма, да и инкапсуляции

так расскажешь?

ну мол реально ж интересно, а то заинтриговал и все

У юзера появились подписки, второй личный счёт (не в рублях, а "в курьерах").

у меня был похожий случай с "ваучерами". Ваучеры можно было пересчитать в деньги, там просто были до ограничения

Конкретно платёж запилил так: Есть собственно те самые AR: PaymentModel и PaymentItemModel. Т.к. на высшем уровне бизнес-логика тут предполагает фактически три действия: - Взять что-то, сделать из этого платёж/счёт; - Подтвердить оплату; При этом после подтверждения оплаты должны быть оказаны некие услуги, которые подразумевает это "что-то". То делаем класс Payments и интерфейс PaymentServiceInterface. Payments имеет методы: make, // создаёт платёж правильным образом addModel, //добавляет в этот платёж цель (заказ/подписку и т.п.) confirm, // подтверждает оплату cancel. // отменяет оплату PaymentServiceInterface имеет почти то-же самое: construct addModel, confirfirm<

cancel, commit

commit нужен для того, чтобы cancel и confirm могли быть отменеы ещё до реального применения, а так-же могли бы накидать исключений. После коммита услуги уже оказаны и рыпаться поздно (и исключений он уже не кидает).

В общем чего я расписываю. payment = Payments.make(User, Type, InvoceId); payment.add(Order); payment.add(Order2); payment.add(Packet); ..... payment.comfirm().commit(); Это что "снаружи". Внутри он на каждое назначение (добавленное через .add()) дёрнет класс реализующий PaymentServiceInterface (сам класс определяется типом назначения, у расзных разный) и подёргает соответствующие методы.

Там уж от реализации зависит. В случае order'ов заказы статусы получат и ещё какаая-то такая хрень произойдёт. В случае подписок там будет юзеру подписа назначена/продлена, всякие баллы начислены и т.п.).

Лан. Пришло время принять волевое решение и назвать класс NevedomayaHernya и запилить хоть что-то.

у тебя куча зон ответственности - там ты одним классом не обойдешься что бы все было ок

Конкретно то что мне нужно сделать можно одним методом вообще сделать. Эта логика не дробится уже.

Зона ответственности тут "посчитать итоговый итог с учётом всех-всех условий, баллов, счетов"

Соответственно знать этой теме надо о заказе и юзере

Зона ответственности тут "посчитать итоговый итог с учётом всех-всех условий, баллов, счетов"

Если у тебя есть класс Счет то можешь решить это через декораторы

Если у тебя есть класс Счет то можешь решить это через декораторы

Счёт в смысле "лицевой счёт", простое поле у юзера нынче.

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

И назвать его Total

Счёт в смысле "лицевой счёт", простое поле у юзера нынче.

т.е. это не обьект? или как у тебя происходит взаимодействие с этим полем, допустим есть User что происходит, когда начинается движение денег на счету?

total = new Total(Order) и можно во вьюшку передать, да отчёт нарисовать а можно по нему платёж создать Payments.make(total)

т.е. это не обьект? или как у тебя происходит взаимодействие с этим полем, допустим есть User что происходит, когда начинается движение денег на счету?

Личный счёт (счета) юзера на данный момент вообще никак не обрабатываются специально. Просто число в базе и всё. Движение можно только из истории платежей достать.

total = new Total(Order) и можно во вьюшку передать, да отчёт нарисовать а можно по нему платёж создать Payments.make(total)

Хотя нет, это наверное фабрика должена быть, ибо там вместо order что угодно может быть и считать это надо иначе совершенно

Хотя нет, это наверное фабрика должена быть, ибо там вместо order что угодно может быть и считать это надо иначе совершенно

Что в классе Order?

Что в классе Order?

Юзер, данные по доставке, список товаров/услуг и из количества. Ну и статусы всякие.

И куда идёт этот Order?

Много куда. Данные из него есть в личном кабинете. Есть в админке. Печатаются для курьеров. Ну и платёж по нему создаётся (сейчас).

Условно говоря я хочу сейчас вместо payment = Payments::make(Order): сделать total = Total::make(Order); payment = Payments::make(total);

Ибо раньше у Order была цена (просто число в рублях), а теперь всё заморочено и нужен "кто-то" кто эти заморочки разрулит насколько возможно.

ERROR: S client not available

Вроде как норм выходит

Если только этот момент не изменится ещё каким-то невероятным образом, что уже нельзя будет так реализовать ?

Ты можешь рефакторить?

рефактори

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

Что такое Payments?

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

Что такое Payments?

Есть два таких класса, один это просто структура данных, а другой обрабатывает платёж. Тут это второе, но их можно было бы даже в один слить. Отвечает он за то, что создаёт платёж, добавляет в него всякие назначения (блин, я в вышестоящих примерах хрень написал, не так оно работает), например тот же Order. Ну и подтверждает/отменяет оплату. Внутри там ещё юзаются классы (реализующие специальный интерфейс), которые реализуют "оказание услуг" которые стоят за назначениями (в случае заказа это тупо статус "оплачен" ему проставить, но где-то и сложные дела).

В реале оно как-то так юзается: payment = Payments::make(User, type, invoice); payment.add(Order); payment.add(....); .... payment.confirm();

type что это?

type что это?

Число (из константы класса). Означает способ оплаты.

invoiceId тоже число и нужно для внешних платёжных сервисов (гоню, строка)

День добрый. Вопрос знающим\имеющим опыт с клиент-серверными приложениями. В общем, представим, что я пилю аналог anki - тобишь это клиент с локальной бд на телефоне и десктопе, и веб-версия с мастер бд. Соответственно, юз кейс - если я пользуюсь приложением без интернета, данные сначала идут в локальную бд, с появлением интернета - синхронизируются с бд где-то на сервере (отправка локальных данных, получение новых). Вопрос - какой самый простой способ это реализовать? На ум приходит только оборачивание всех моих юз кейсов (добавить карточку, удалить, обновить) в паттерн command, и соответсвенно класть эти command-ы в очередь. Далее, при появлении интернета, доставать их из очереди и отправлять их на сервер (через rest api, еще как-то).

нормальное решение. почему сомневаешься?

нормальное решение. почему сомневаешься?

боюсь оверинженеринга

у меня изначальная цель этого всего - запилить свой велосипед, плюс попробовать DDD (правда, леплю на питоне, а там примеров DDD немного)

Решение подходящее. Если реализовать его в минимально необходимом виде, будет хорошо, без оверинжиниринга

Решение подходящее. Если реализовать его в минимально необходимом виде, будет хорошо, без оверинжиниринга

Ок, спасибо. Хотя тут же возникает вопрос, что есть "минимально необходимый вид", и как его достичь.

И как я понимаю, юз кейсы начинают лепить как command-класс, а не как простой метод, как раз таки в случае нескольких платформ?

Ок, спасибо. Хотя тут же возникает вопрос, что есть "минимально необходимый вид", и как его достичь.

TDD поможет в определении "минимально необходимого"

И как я понимаю, юз кейсы начинают лепить как command-класс, а не как простой метод, как раз таки в случае нескольких платформ?

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

ну и опять же не понятно зачем тебе command bus

всем привет. какой паттерн больше к api подходит? я нашел два похожих - посредник и фасад

интересный вопрос, что такое api в твоем вопросе?

для создания api подходит просто public интерфейс у объекта :)

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

я просто начал класс писать, а он начал слишком много знать и уметь

я просто начал класс писать, а он начал слишком много знать и уметь

посмотри имплементацию json apihttps://github.com/tobscure/json-api или можешь сюда поконтрибутить https://github.com/f3ath/json-api

посмотри на sinatra/finatra/silex/express/miku