Как компания-разработчик, довольно часто для разных проектов требуется (почти) одинаковый код. Потребность в модульной системе становится все более и более требовательной, так что я максимизирую повторное использование кода как на переднем, так и на внутреннем уровнях.
Важно то, что я не хочу сокращать ограничения, а это означает, что клиент почти всегда сможет получить те функции, которые ему нужны. Если эта функция окажется пригодной для повторного использования в других бизнес-случаях, я бы включила ее в один из «основных» модулей, в противном случае мы бы (расширили / переопределили существующие модули и) создали отдельный модуль.
Back-конец
Теперь на бэк-энде я решил это, и, возможно, стоит объяснить это на примере.
Допустим, у вас есть модуль Core , модуль E-Commerce и модуль Marketplace .
- Для всех модулей потребуется портал / бэк-офис / административная панель.
- Модуль электронной коммерции должен иметь отдельный веб-проект для интернет-магазина.
- Модуль Marketplace должен иметь отдельный веб-проект Marketplace.
То, как я решил это в C #, выглядит так:
Итак, на изображении выше вы можете видеть, что контроллеры в модулях расширяются, переопределяя его. Все логики домена и приложения одинаковы (не показаны): большинство вещей виртуализированы, поэтому я могу переопределить их при необходимости в рамках одного бизнес-проекта. Таким образом, если один бизнес-проект не соответствует требованию с помощью стандартного модуля «Электронная коммерция», он может расширить или создать дополнительные логические элементы / контроллеры для реализации функций.
Итак, для приложения portal я не вижу проблем. Я могу легко лениво загружать (угловые) модули в зависимости от настроек. Это может быть одно веб-приложение для всех бизнес-случаев, которое не требует особого ухода. Таким образом, хотя на нем показаны два отдельных веб-приложения Portal, они получат одинаковый угловой интерфейсный код. Разумеется, они просто будут разделены на разные серверы.
Фронтальный
Но заходя в интернет-магазин и рынок модулей / проектов:
- Они оба могут иметь совершенно разный дизайн.
- И то, и другое может использоваться разными предприятиями, каждый из которых имеет свою уникальную систему оформления заказа / поток на рынке.
- Но загрузка продуктов, отображение позиций на рынке, регистрация / вход в систему и оплата с точки зрения функциональности в основном равны.
- Некоторые компоненты, созданные в модуле core и используемые на портале, также должны быть в состоянии использоваться в приложении интернет-магазина / торговой площадки.
Итак ... как мне сделать это правильно в angular (7)? То, что я знаю до сих пор и до сих пор работало.
Сходства между бизнес-проектами
Поскольку все внутренние контроллеры будут иметь фиксированную маршрутизацию, вызовы http одинаковы для всех проектов. Один проект может расширить внутренний контроллер и вести себя по-другому, но это не изменит маршрутизацию. Если для одного проекта требуются дополнительные функции, он, скорее всего, также потребует отдельного углового модуля / компонента.
Некоторые компании могут захотеть показывать компоненты немного по-другому (на портале). Это может быть достигнуто либо наличием специфичных для проекта файлов style.less (скорее всего, в любом случае, необходимых для основных цветов макета), либо "переопределением / заменой" компонента в соответствии с этим ответом .
Несмотря на то, что интернет-магазин и торговая площадка - это совершенно разные компании, они имеют схожие функции, такие как: вход в систему, страница оплаты для выставления счетов, показ деталей счета, загрузка фотографий, выбор времени и выбора страны / языка + локализация.
Иногда требуются дополнительные поля, этого можно достичь с помощью CRM-подобного метода, настроив его в базе данных и загрузив их в представление для отдельных http-вызовов.
Различия между бизнес-проектами
Я вижу различия в нескольких «этапах», от незначительных изменений до больших изменений:
- Небольшие изменения в дизайне: Это потребует лишь небольшого изменения общего макета и может быть достигнуто путем изменения стиля, специфичного для компании.Если этого недостаточно или потребуется много кода в основном файле style.less, мы хотели бы заменить файл component.less.Пример: страница входа в систему.
- Значительные изменения в дизайне: Функциональность компонента будет такой же, но для компонента потребуется совершенно другой HTML-файл.Пример: страница профиля учетной записи.
- Функциональные изменения: HTML-файл и файл поменьше могут фактически совпадать, но в функциональности / поведении компонента требуются незначительные или существенные изменения.Пример: может потребоваться автоматическое сохранение данных, может потребоваться кнопка подтверждения.
- Завершить другой компонент: Решено, см. 2. в сходствах.
Остальные вопросы
- Как я могу загрузить другой стиль для определенного компонента?Аналогично предоставлению нескольких файлов дизайна для мобильных устройств, планшетов и компьютеров.Но тогда на основе переменной среды?
- Как получить полный другой файл .html для той же функциональности компонента?
- Возможно, может быть полезно иметь конфигурацию маршрутизации для каждой компании, чтобы легкопереключиться на пользовательский компонент вместо одного из компонентов по умолчанию в одном модуле?
- Как бы я структурировал свои папки?Основным способом ASP.NET является создание углового проекта в рамках веб-проекта, но когда я хочу поделиться компонентами между всеми различными веб-проектами, я не вижу, как это будет работать.Я думаю, что я предпочитаю иметь угловой проект в рамках веб-проекта, потому что они довольно хорошо интегрируются друг с другом, также позволит избежать накладных расходов на аутентификацию на основе токенов, если не размещать их отдельно.
Замечание
Один из способов, который я могу придумать, - это создать свои собственные частные пакеты npm, создать модуль «core», модуль «ecommerce» и модуль «marketplace».И затем каждый фактический бизнес-проект импортирует эти пакеты npm.Я думаю, что для готового к работе кода это будет работать, но во время разработки я не уверен, как это будет работать, чтобы мне не приходилось публиковать свой пакет каждый раз, прежде чем я смогу использовать его в другом проекте.Для этого мне все равно придется решить вышеуказанные вопросы: как я могу снова расширить / переопределить модуль после его импорта.Если бы у меня была возможность иметь ng build --watch на них, это было бы хорошо, но я думаю, что это, вероятно, потребует интенсивной конфигурации, когда я хочу автоматизировать это на CI / CD?Также учитывая тот факт, что он должен легко отлаживаться во время тестирования одного проекта.
В основном я ищу лучшие практики.До сих пор было сложно найти решения, поскольку «модули» и «угловые» идут рука об руку, поэтому большинство решений сосредоточены исключительно на отдельных модулях в рамках одного проекта.
У меня есть эскиз архитектуры того, как я буду структурировать угловые модули:
