damsel/doc/domain.md
Andrew Mayorov 4b6544893b HG-30: Domain redesign (#64)
* HG-30: Dump a preliminary domain redesign

* HG-30: Fix implicit requiredness

* HG-30: Bring contractor object back to domain

* HG-30: Use the term 'Cash' as a notion of financial resources

* HG-30: Describe what 'Terminal' is more thoroughly

* HG-30: Bring together a couple of known unsolved problems

* HG-30: Throw down some notes on planned domain structure
2016-10-10 16:14:58 +03:00

4.6 KiB
Raw Blame History

Предметная область

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

Участники

                      Party
                        |
                     Contract
                    /        \
             Services        Shops
            /    |    \
    Payments  Payouts  ...
    Service   Service
       |         |
     Terms     Terms

В системе, есть участники, с которыми у нас заключён договор на предоставление этим участникам различных услуг. В договоре указаны пакеты услуг, которые предоставляет система, например:

  • услуги по процессингу платежей,
  • услуги по проведению выплат.

В рамках пакета услуг по проведению платежей система даёт возможность участникам (в данном случае, мерчантам) проводить различные процессы, например:

  • простые платежи,
  • возмещения,
  • задержанные платежи,
  • рекуррентные платежи.

С пакетом услуг (каждым процессом?) связаны условия их проведения, например, с пакетом услуг по проведению платежей связаны:

  • ограничения по категориям товаров и услуг, валютам, методам оплаты, возможностям возмещений (?);
  • лимиты на количество денежных средств, оборот за определённое время;
  • комиссии системы.

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

Провайдеры с терминалами в общей картине естественное отражение модели участников с магазинами в том смысле, что в отличие от участника, каждый провайдер согласно некоторому договору предоставляет услуги системе:

                     Provider
                        |
                     Contract
                    /        \
             Services        Terminals
            /         \
     Payments           ...
    Processing
     Service
        |
      Terms

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

Процессы

В рамках каждого процесса необходимо проведение различных взаимодействий c различными участниками по определённым протоколам, например, в рамках процесса платежа нужно провести:

  • техническое взаимодействие,
  • финансовое взаимодействие.

Для проведения технического взаимодействия в процессе платежа необходимо обладать информацией о технических протоколах всех третьих сторон и их параметрах, в нашей системе это:

  • мерчант и его магазин,
  • провайдер и его терминал,
  • набор прокси с их опциями.

Для проведения финансового взаимодействия в процессе платежа в свою очередь необходимо обладать:

  • корректным графом финансовых потоков,
  • набором счетов всех участников: мерчант, провайдер, система.