Модел на данни за абонамент за SaaS

SaaS (Софтуер като услуга) е един от трите основни компонента на облачните изчисления. Обикновено SaaS приложенията са уеб-базирани и могат да обработват много различни потребители едновременно. Решенията, базирани на абонамент, са много популярни SaaS предложения. Някои добре познати SaaS продукти включват Microsoft Office 365, Amazon Web Services (AWS), Slack, Jira, Stripe и (разбира се) Vertabelo! Днес ще разгледаме модел на данни, който би ни позволил да управляваме SaaS абонаменти.

Идеята

SaaS продуктите могат да бъдат много различни. Някои таксуват редовно за услугите си, напр. месечно или годишно; други таксуват само за количеството време или използвани ресурси (или комбинация от тези две). За да опростя нещата в тази статия, ще се съсредоточа само върху месечните платени абонаменти.

Да предположим, че имаме няколко различни SaaS решения и трябва да проследяваме всички наши абонати в една база данни. Това може да е така, когато предоставяме решения за бази данни (например Amazon DynamoDB), инструменти за анализ (например Amazon Athena) или приложения за роботи (например AWS RoboMaker). Всъщност, ако погледнем Amazon, можем да видим, че има много различни налични приложения. Ще изберем само тези, от които наистина се нуждаем.

Модел на данни

Моделът се състои от три предметни области:

Users & groups
Software & plans
Subscriptions, plans & payments.

Ще опишем всяка от тези тематични области в реда, в който са изброени.

Раздел 1:Потребители и групи

Users & groups предметната област съхранява информация за всички потребители на нашето приложение. Ще приемем, че потребителите могат да бъдат групирани, напр. когато една компания иска да закупи лицензи за няколко служители. Ще създадем група, дори когато само един потребител принадлежи към нея. Това ще ни даде гъвкавост по-късно да добавяме нови членове към тази група.

Най-важната таблица тук е user_account маса. Ще го използваме за съхраняване на всички подробности, свързани с потребителските акаунти. Това са:

first_name & last_name – Името и фамилията на потребителя. Моля, имайте предвид, че всеки съхранен тук потребител е частно лице.
user_name – Потребителско име (избрано от потребителя).
password – Хеш стойност на паролата на потребителя. (Потребителите задават свои собствени пароли.)
email – Имейл адресът на потребителя, зададен по време на процеса на регистрация.
confirmation_code – Кодът, използван по време на процеса на потвърждение по имейл.
confirmation_time – Когато регистрацията/потвърждението е завършено.
insert_ts – Времевата марка, когато този запис е бил първоначално вмъкнат.

Потребителите могат да създават групи; групите имат предварително дефинирани типове. Списък с всички възможни типове групи се съхранява в user_group_type маса. Всеки тип е УНИКАЛНО дефиниран от своя type_name . Ние също така ще дефинираме минималния и максималния брой членове на групата, разрешени за всеки тип група. Този диапазон се дефинира с две стойности – members_min (долната граница) и members_max (горната граница).

Докато създават нов акаунт, потребителите ще избират и своята потребителска група. Това ще създаде нов запис в user_group таблица, препращаща към избрания тип група и съхраняваща времевата марка (insert_ts ), когато този запис е бил вмъкнат. customer_invoice_data атрибутът е текстово описание на това, което ще отпечатаме във фактурата за тази потребителска група.

Последната таблица в тази тематична област е in_group маса. За всяка група ще съхраняваме списък с всички нейни членове. Освен препратки към потребителската група (user_group_id ) и потребителски акаунт (user_account_id). ), също така ще съхраняваме клеймото за време, когато потребител е бил добавен към групата (time_added ) или премахнати от групата (time_removed , което ще съдържа стойност само ако потребителят е премахнат). Ще имаме също флаг, който да обозначава дали потребителят е group_admin или не. Администраторите на групата могат да актуализират членовете на групата и да добавят нови членове.

Раздел 2:Софтуер и планове

След това трябва да дефинираме всичко, което ще предложим на нашите (потенциални) клиенти. Може да предложим само един тип софтуер, но има голяма възможност да имаме няколко различни оферти. Често срещан пример за този случай е наличието на SaaS инструмент, който е отделен от неговото приложение за анализ, напр. Stripe и Stripe Sigma. Ще разгледаме такива случаи в нашия модел на данни.

Ще започнем с software маса. В този речник ще съхраняваме списък с всички наши SaaS предложения. За всеки от тях ще съхраняваме:

software_name – УНИКАЛНО име на софтуер.
details – Всички подробности, описващи този софтуер.
access_link – Местоположение или връзка, където имаме достъп до този софтуер.

Трябва да можем да предложим нашите SaaS решения в един или повече различни планове. Всеки план съдържа различни опции. Например, бихме могли да имаме първокласен план, който включва всички опции, които предлагаме, и основен план, който включва само най-важното. Ще съхраняваме всички отделни планове в plan маса. За всеки план ще дефинираме:

plan_name – Името, което сме избрали за този план. Заедно с препратката към софтуера (software_id ), това формира алтернативния/УНИКАЛЕН ключ на тази таблица.
user_group_type_id – Справка, обозначаваща вида на групата, която може да използва този план. Това може да бъде група с един потребител или стандартна група. Тази справка също така дефинира максималния брой членове на групата за този план – напр. ако нашият план позволява пет различни акаунта в един абонамент, трябва да посочим подходящия user_group_type .
current_price – Текущата цена за този план.
insert_ts – клеймото за време, когато този запис е бил вмъкнат.
active – Флаг, обозначаващ дали този план е активен или не.

Вече споменахме, че плановете за същия софтуер ще идват с различни опции. Списък с всички различни опции се съхранява в option речник. Всяка опция е УНИКАЛНО дефинирана от своя option_name .

За да присвоим опции на различни планове, ще използваме option_included маса. Той съхранява препратки към свързания план (plan_id ) и опция (option_id ). Тази двойка, заедно с date_added атрибут, формира УНИКАЛНИЯ ключ на тази таблица. date_removed атрибутът ще съдържа стойност само ако решим да премахнем определена опция от план. Това може да се случи, когато изградим нова опция, за да заменим старата, или решим да нямаме вече дадена опция, защото малко хора я използват.

Последната част от тази тематична област е свързана със специални или промоционални оферти. Като цяло подобни оферти предоставят на клиентите повече обслужване за по-малко пари и продължават за определен период от време. Те могат да бъдат насочени към придобиване на нови клиенти или продажба на надстройки на планове (или по-широк набор от услуги) на съществуващи клиенти.

Всички наши промоционални оферти се съхраняват в offer маса. За всяка оферта ще трябва да дефинираме:

offer_name – УНИКАЛНО име, което избрахме за тази оферта.
offer_start_date и offer_end_date – Периодът от време, през който тази оферта е налична.
description – Подробно текстово описание на офертата.
Отстъпки:Нуждаем се от гъвкавостта, за да имаме два вида отстъпки – отстъпка на базата на фиксирана сума (например получаване на отстъпка от $50) и процентна отстъпка (например спестяване на 25%). Ако предложим фиксирана отстъпка, ще вмъкнем тази стойност в discount_amount атрибут; ако предложим процентна отстъпка, ще добавим този процент в discount_percentage атрибут.
Продължителност:Тук ще използваме същата логика, която използвахме за отстъпките. В някои случаи офертите ще продължат за определен брой месеци (например 24 месеца след регистрация на клиенти); в тези случаи ще дефинираме duration_months стойност. Други оферти ще бъдат валидни до определена фиксирана дата (напр. до 31 декември 2019 г.); за тях ще дефинираме датата и ще я съхраняваме в duration_end_date атрибут.

Ще използваме останалите две таблици в тази тематична област, за да определим какво съдържа всяка оферта и какви предпоставки има тя. За тази цел ще използваме две таблици:include и prerequisite . Те споделят една и съща структура и съдържат една и съща УНИКАЛНА двойка offer_id – plan_id . Някои оферти може да нямат никакви предпоставки, докато други – напр. ако предлагаме отстъпка за надграждане до план с повече потребители или абонамент за софтуер за потребители на друг софтуер.

Офертите могат да бъдат сложни, така че ще дам няколко примера.

Ако в момента използваме план А и имаме предложение да надстроим до план Б, това е лесно.
Ако имаме две оферти, „План А надстройва до План Б“ и „План Б надгражда до План В“, трябва да създадем още една оферта:„План А надгражда директно до План В“. Това позволява на потребителите да надграждат своите планове с една стъпка, а не с две. Един пример за такова надграждане е промяната на абонамент, който в момента позволява пет потребители на група, към такъв, който позволява 20 потребители на група, без да се спира на междинен план с десет потребители на група по пътя.
Ако група използва продукт А, бихме могли да имаме специална оферта да се абонираме за продукти Б и В на промоционална цена. Бихме могли също да имаме две отделни оферти, за да се абонираме само за продукт Б и само за продукт В.

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

Раздел 3:Абонаменти, планове и плащания

Последната тематична област свързва двете по-рано споменати области и е истинското сърце на този модел.

Всички абонаменти се съхраняват в subscription маса. Ще третираме всеки различен план като отделен абонамент, дори ако тези абонаменти/планове са резултат от една и съща оферта. Причината за това е, че ще можем да управляваме абонаментите поотделно – напр. анулираме ги отделно, ако искаме. Тук ще трябва да дефинираме редица подробности:

user_group_id – Идентификационният номер на групата, която се абонира за този план. Това е важно, защото потребителите няма да бъдат абонирани поотделно; те са абонирани индиректно, като част от групата.
trial_period_start_date и trial_period_end_date – Долната и горната граница на пробния период (ако има такъв) за този абонамент.
subscribe_after_trial – Флаг, обозначаващ дали абонаментът ще бъде подновен автоматично след изтичане на пробния период (ако има такъв).
current_plan_id – Текущият план за този абонамент. Ако абонаментът вече не е активен, този атрибут ще съдържа стойността на последния активен план.
offer_id – Препратка към офертата, с която е свързан този абонамент. Този атрибут ще съдържа стойност само ако този абонамент е резултат от определена оферта.
offer_start_date и offer_end_date – Долната и горната граница на периода, през който тази оферта е била активна. Тези атрибути ще бъдат дефинирани само ако този абонамент е резултат от определена оферта.
date_subscribed – Когато тази група се е абонирала за този абонамент.
valid_to – Последната дата на валидност на този абонамент. В случай на месечен абонамент можем да очакваме, че valid_to ще бъде зададен до края на текущия месец. Ако клиент се отпише по всяко време в рамките на един месец, той пак ще може да използва софтуера си до края на този месец.
date_unsubscribed – Датата, на която тази група се е отписала от този абонамент. Можем да очакваме, че тази дата ще бъде зададена ръчно от администратора на групата, когато групата реши да не използва услугата повече. Въпреки това може да се настрои и автоматично, според предварително зададени критерии – напр. автоматично отписване на група от тяхната услуга, ако има две или повече неплатени фактури.
insert_ts – клеймото за време, когато този запис е бил вмъкнат.

Абонаментните планове често се променят с течение на времето. За да поддържаме пълна история на всички наши планове, ще съхраняваме всички промени в плана в plan_history маса. За всеки запис тук ще ни трябва:

subscription_id – Идентификационният номер на съответния абонамент.
plan_id – Идентификационният номер на свързания план.
date_start и date_end – Периодът от време, през който този план е бил активен.
insert_ts – клеймото за време, когато този запис е бил вмъкнат.

Последната таблица в нашия модел ще съхранява нашите invoices . За всяка фактура ще запазим следните подробности:

customer_invoice_data – Описание на клиента, таксуван за тази фактура. Това ще бъдат данните от user_group.customer_invoice_data в момента на генериране на фактурата.
subscription_id – Идентификационният номер на съответния абонамент.
plan_history_id – Идентификационният номер на плана, активен през този период на фактуриране.
invoice_period_start_date и invoice_period_end_date – Интервалът от време (напр. от 1 януари 2019 г. до 31 януари 2019 г.), обхванат от тази фактура.
invoice_description – Кратко текстово описание на фактурата.
invoice_amount – Сумата на дължимото плащане за тази фактура.
invoice_created_ts – Когато тази фактура е генерирана и вмъкната в таблицата.
invoice_due_ts – Кога е дължима тази фактура.
invoice_paid_ts – Печатът за датата на плащане на тази фактура.

Кажете ни какво мислите за SaaS модела на данни

Предполагам, че повечето от вас са срещали SaaS или като разработчик, или като потребител. Очаквам с нетърпение вашето отношение към него и този модел на данни. Чувствайте се свободни да споделите своя опит и предложения в коментарите по-долу.