Архив рубрики: Разработка

База знаний в saas-проекте

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

Небольшой список требований к такой базе знаний и движкам, для их построения:

  1. Актуальность. Информация всегда должна быть актуальной. Поменялся интерфейс системы — меняйте скриншоты в базе знаний. Добавили новый функционал — добавьте информацию об этом в базу знаний.
  2. Структурирированность. Информации о продукте становится все больше и больше. Правильное ее структурирование обеспечит удобство использования.
  3. Поиск. Он просто должен быть и быть классным +)
  4. Простота ведения. Интерфейс администратора/оператоа должен быть элементарным (привет, конфлюенс!)

Ну и хватит пока.

Под требования выше подходит практически любая современная CMS или вики-движок, имеются и специализированные решения.

В голове рождаются мысли о написании такого движка на Symfony, постараюсь их отогнать =)

BitBucket прекращает поддержку Mercurial

Когда-то давно я пришел на Bitbucket именно из-за поддержки и Git и Mercurial.

Времена идут, продуктовые стратегии меняются, старое выпиливается.

Самое главное, что пользователям дается время свалить с битбакета или мигрировать на Git.

Про DDD

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

 

https://t.me/symfony_php

Про CentOS…

Пустой дистрибутив. Абсолютно любое действие в нём начинается с tar zxf, configure, make install.  Разговоры о его надежности заканчивается через полчаса после необходимости поставить какой-нибудь htop или monit.  Ещё через час после разломанного в крошево дистрибутива заканчиваются рассказы о том, что существуют какие-то внешние репозитории, в которых что-то есть.

Про фичи, контексты и boundary context

Фичи формируют контексты (boundary context). Контексты пересекаются но в целом весьма изолированы. Их нутро не зависит друг от друга.

Возьмем к примеру каталог товаров и прикинем какие у нас тут есть контексты:

  • пользователи — авторизация, восстановление доступа, управление профилем
  • ордеры — весь цикл жизни ордера в системе
  • каталог товаров — управление каталогом, просмотр деталей о продукте
  • поиск — весь поиск.

В этом примере наиболее интересный «модуль» — это поиск. Он может искать для нас продукты в каталоге и ордеры. Но они ничего не знает о ордерах или продуктах. Скажем когда мы ищем ордеры — мы просим модуль поиска найти для нас «ордеры» и он всего-лишь вернет нам айдишки и информацию которая важна нам для поиска. Далее для этих айдишек мы можем уже запросить детали у модуля каталога.

Синхронизация этих модулей — ивенты. Кто-то обновил продукт — кидаем ивент — синхронизируем данные в других контекстах.

Профит тут в том что мы можем отдельно посадить чувака заниматься поиском, и отдельно чувака заниматься ордерами. Можем перевести поиск на свою СУБД которая хорошо умеет полнотекстовый поиск (например эластика). И при этом если у нас добавляются фичи в каталог — это не сильно влияет на поиск.

 

https://habrahabr.ru/company/englishdom/blog/328550/