Некоторые пользователи сети потратили два месяца на создание торгового центра b2c.Стек технологий — sass, jquery и thinkphp.Изучив набор, они столкнулись с множеством проблем. Например: у меня нет представления о процессе разработки проекта, и я не знаю, где найти соответствующую информацию. Поэтому он задал несколько вопросов:
- Каковы основные компоненты процесса разработки проекта?
- Как определить общую модель работы проекта на ранней стадии?
- Как спроектировать модель данных?
Ниже приведены некоторые карты мозга этого пользователя сети в начале проекта.Из-за проблем с дизайном части возвратов, купонов и скидок в конце не были завершены:
В ответ на эти вопросы Юн Цзянь, технический архитектор отдела Сямэнь, написал эту статью, чтобы ответить на них один за другим.
Каковы основные компоненты процесса разработки проекта?
Что касается процесса разработки проекта, мое понимание в основном такое же, как и у этого пользователя сети, однако в общих командах будут такие роли, как бизнес, продукт, сервер, внешний интерфейс, клиент и тестирование, поэтому общая стоимость коммуникации составляет относительно Это будет намного выше Общий процесс примерно таков: обзор требований, обзор технического решения / планирование проекта, обзор тестового примера, разработка, тестирование, предварительный просмотр функций, выпуск, онлайн-оттенки серого / большой объем.
На самом деле, шаг «проектирования общего бизнес-процесса», упомянутый этим пользователем сети, должен быть подтвержден путем коммуникации между продуктом и бизнесом заблаговременно до технического вмешательства. «Проектирование модели данных» должно относиться к этапу технического решения, входящего в ее состав. Для студентов, изучающих технологии, весь процесс должен быть сосредоточен на двух частях: обзоре спроса и разработке технического решения.Позвольте мне кратко рассказать о некоторых моих взглядах.
Что касается спроса, я уже видел введение в философию работы Маска, и я думаю, что это очень хорошо. Речь идет о процессе итерации спроса. Рекомендуется выполнить следующие пять шагов:
- Формулируя требования, пусть ваши требования не будут такими глупыми (ха-ха, то есть надейтесь, что требования максимально разумны, не выдвигайте их и обнаружите, что они бесполезны)
- Попробуйте удалить компонент или процесс, этот шаг позволит вам узнать, что такое основной компонент и процесс.
- Оптимизация, только когда вы дойдете до третьего шага, и есть оптимизация.Не оптимизируйте на первом шаге, пусть ваша оптимизация сосредоточится на необходимых компонентах и процессах.Вот где многие инженеры склонны к ошибкам.
- Ускорьте время первых трех циклов, ваши действия слишком медленные, идите быстрее~, до этого не ускоряйтесь
- Последний шаг — автоматизация
Первые три шага могут дать нам хорошие ориентиры для формулирования некоторых бизнес-требований.В фактическом процессе проекта это также позволяет нам подумать о том, каковы наши основные требования, и сосредоточить наши ограниченные силы на том, что мы должны сделать. получить лучшие результаты. Еще один момент касается дизайна технического решения.Я не думаю, что есть фиксированный шаблон.Ключевым моментом является уточнение основных технических вопросов, которым необходимо уделять больше внимания в течение всего процесса технического проектирования, включая, помимо прочего, выбор технологии. , диаграмма последовательности бизнес-взаимодействия, автомат сущностей, моделирование данных, прикладная/физическая/бизнес-архитектура, а также гарантии высокой доступности, риски стабильности и т. д.
Как определить общую модель работы проекта на ранней стадии? То есть эскизный проект всего проекта?
Суть этой проблемы на самом деле проблема моделирования предметной области.Возвращаясь к первой картинке предмета, когда речь идет о моделировании предметной области, я понимаю, что мы должны сначала прояснить основную сущность нашего бизнеса, то есть сущность предметной области. ., на этой картинке мы можем четко видеть три части: пользователь, продукт, заказ (конечно, это может быть уточнено до некоторых сущностей: корзина, список логистики, оценка и т. д., вот только простой пример), что отражено в дизайне. В приведенном выше архитектуре приложений всего бизнеса неизбежно потребуются три центра: пользовательский центр, товарный центр и центр заказов. Когда модель подтверждается, также определяется поведение самой модели и отношения между моделями.Эта диаграмма предмета в основном используется для представления некоторых общих бизнес-процессов, включая: сущности, поведение пользователей, логические суждения и т. д. Для этих предложений относительно лучше описать эти предложения с помощью «диаграмм последовательности», которые могут быть относительно яснее. для описания систем, объектов и взаимодействий между объектами и системами.
Просто нарисуйте взаимосвязь и взаимодействие между пользователем и несколькими системами, вы сможете увидеть, какие системы требуются, какие возможности требуются этим системам и как пользователи взаимодействуют с этими системами.
PS: рисунок здесь неполный, игнорируя обработку всех проблем с ненормальной логикой и согласованностью данных, включая последующий процесс оплаты и процесс конечного автомата последующих заказов после того, как пользователь создает заказ.Просто дайте демоверсию.
Что касается «Пользовательского центра», можно поддерживать большую часть регистрации/входа/выхода/изменения личной информации в пользовательском центре, но здесь нецелесообразно размещать купоны, заказывать записи запросов и заказывать комментарии. купон принадлежит маркетинговому домену и должен быть подсистемой «купон», принадлежащей маркетинговому домену.Система может предоставлять возможность запрашивать купон в соответствии с идентификатором пользователя. Вести учет заказов и запросы целесообразнее в «Центре заказов», а «Комментарии» также можно вынести в отдельную подсистему.
Короче говоря, доменная модель системы определяется в соответствии с бизнес-требованиями, затем распределяются обязанности каждого домена, разбираются функции, а затем постепенно совершенствуется каждый поддомен. После того, как полка всего проекта настроена, последующее расширение функций будет относительно простым.
Как спроектировать модель данных? Или как оформить таблицу данных?
Первым шагом в проектировании базы данных является понимание бизнес-требований. Иногда разные бизнес-требования приводят к большим различиям в моделировании данных. Это то, что нам нужно уточнить перед проектированием.
После этого в соответствии с бизнес-формой определяются сущности домена, такие как товары, заказы, пользователи и т. д., участвующие в электронной коммерции.Домен товара также включает в себя SPU, SKU, информацию о категории и т. д.
Проектирование модели данных в соответствии с функциональными требованиями внешнего интерфейса, упомянутыми в теме, подходит для простых требований, но если она разработана таким образом для сложных предприятий, если функциональные требования внешнего интерфейса изменятся в будущем, преобразование вся система будет катастрофической Да, рекомендуется установить набор надежных моделей предметной области для защиты и отделения требований к внешнему интерфейсу от базового хранилища. При моделировании уровня БД выполняется правильная абстракция, избыточность и др. Данные проходят через объекты предметной области в системе, а страница представляет собой всего лишь визуализацию объекта VO.
Кроме того, при разработке таблицы данных необходимо учитывать различные факторы, такие как оценка объема данных (требуются ли подбаза данных и подтаблица), метод хранения (выбор технологии хранения), наличие «горячих» данных и возможность резервирования будущего расширения и т. д.
Что касается моделирования БД, рекомендуется использовать диаграмму ER для проектирования, и связь между таблицами данных будет относительно ясной. Ниже приведена простая демонстрация
О технологии баз данных MySql порекомендуйте книгу:«Высокопроизводительный MySQL»
чертежное оборудование
Наконец, что касается рисования, я рекомендую несколько полезных инструментов для рисования:
- ОмниГраффл:www.omnigroup.com/omnigraffle
- рисовать.IO:drawio-app.com/examples/
- ЗаводUml:растение UML.com/this/sequence…