AFINA agency

Как начать SaaS-проект № 1: Модель данных

Я прочитал много статей, пытаясь охватить тему шаблонов технического проектирования, но в основном они описывают гигантский технологический стек. Это не полезно для людей, которые хотят начать бизнес.
Перевод https://www.lunadio.com/blog/how-to-start-a-saas-project-1-data-model
Если ваш приоритет - решить реальную проблему как можно быстрее и заработать деньги, вы не хотите тратить время на программирование!
Допустим, вы создали целевую страницу для своей идеи и собрали кучу писем. Теперь люди ждут актуального решения - время строить! Как правило, ваши цели:
  1. Фантастический пользовательский опыт - чтобы ваши пользователи были счастливы
  2. Строить как можно меньше - чтобы иметь возможность быстро двигаться
  3. Быстрое развитие - так что вы можете сосредоточиться и на маркетинге
  4. Отказоустойчивость системы - возможность легко обнаруживать и исправлять ошибки
  5. Легко для индивидуального разработчика - у вас нет команды, сделайте это преимуществом
Имея это в виду, давайте создадим что-нибудь?

Эта статья является частью серии о технических шаблонах проектирования для создания SaaS-проекта. Сегодня я расскажу, почему вы должны начать с данных в первую очередь и как они помогут вам в будущем. Будущие части будут сосредоточены на интерфейсе, бэкэнде, хостинге, CDN, доставке электронной почты и всем, что вам нужно для быстрого создания отличного продукта.

Заказать no code разработку

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

Имейте в виду: всегда выбирайте технологию, с которой вы наиболее знакомы

Сейчас не время изучать React или использовать GraphQL впервые. Если вы разработчик, скорее всего, у вас уже есть прочная основа в чем-то.

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

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

Часть 1 - Навести порядок в сложности

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

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

Решение: сначала выясните функциональные требования и модель данных .

  • К каким основным сценариям использования обращается ваш продукт?
  • С какими данными вы работаете?
  • Как будут взаимодействовать данные?
Наличие ответов на эти вопросы до того, как вы перейдете к коду, позволит вам создавать уверенность и скорость позже. Кроме того, невозможно создать интуитивно понятный пользовательский интерфейс без предварительного понимания данных. Ваша цель - создать MVP - «V» означает жизнеспособный , не забывайте об этом.

1. Основные варианты использования

Наличие четкого представления о том, чего должен достичь ваш MVP, поможет вам быстрее и эффективнее принимать решения. Попробуйте свести его в список или несколько предложений.

Pro-tip: Завершите каждое предложение «для того, чтобы…». Это заставляет вас сосредоточиться на реальных преимуществах, а не только на функциях.

Например, в случае FeedBear это было:
  • Компании создадут проект FeedBear, чтобы иметь все отзывы в одном месте.
  • Их клиенты будут отправлять отзывы, чтобы их идеи были услышаны и, возможно, реализованы.
  • Компании будут создавать несколько плат обратной связи в рамках своего проекта, чтобы разделить различные виды обратной связи.
  • Обновление статуса сообщения отправит уведомление всем, кто проголосовал, чтобы держать их в курсе.
  • И так далее …

2. Базовые объекты и их атрибуты

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

Перейдите к своим функциональным требованиям из предыдущего раздела и найдите сущности. Назовите каждого, используя существительное в единственном числе . Также перечислите все возможные атрибуты, которые вам нужно сохранить. Например:

  • Проект (название, поддомен, логотип,…)
  • Доска обратной связи (имя,…)
  • Пользователь (имя, адрес электронной почты, пароль, ...)
  • Сообщение (название, тело, статус,…)
  • Уведомление (название, тело, ...)
Заметьте, я не писал «Статус сообщения» как объект, а как атрибут . Граница между сущностями и их атрибутами довольно тонкая, поэтому я использую простое правило:

Какую информацию я храню в < item > ?
Если ответ только «его родитель», это атрибут. В противном случае это сущность. В моем случае «Статус сообщения» является атрибутом, потому что единственное, что мне нужно знать, это какой статус сообщения. Если бы я хотел знать, когда он был в последний раз изменен или кем, мне нужно было бы сделать это отдельным объектом.

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

3. Отношения

Когда вы правильно определяете отношения между вашими данными, вы избегаете дублирования. Дело в том, чтобы иметь единый «источник правды» для каждой информации. Любая другая сущность, которая работает с этой информацией, получит ее из этого источника.

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

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

Почему это важно?

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

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

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

Я в основном использую карандаш и бумагу для рисования. Это позволяет мне быстро повторять. Когда вы закончите, сохраните его в цифровом виде для дальнейшего использования. Есть много специализированных инструментов, но Figma / Sketch тоже отлично работает.

Резюме

Теперь вы должны иметь общее представление о ваших данных - что вам нужно хранить и зачем вам это нужно. Это первый шаг к достижению ваших целей SaaS. Каждый шаг, который вы предпримете сейчас, будет основан или проинформирован вашей моделью данных.

В следующих частях этого руководства я напишу о внешнем интерфейсе и внутреннем интерфейсе. И хостинг, CDN и почтовые сервисы. Что вам нужно и самое главное - что вам не нужно.

Заказать no code разработку

После уточнения деталей мы можем приступить к вашему проекту
Made on
Tilda