Регистрация  |  Вход

Архитектурные дилеммы в СФ разработке

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

начну с двух примеров, но в самом начале предлагаю немного "раскидать" варианты исходных ситуации, так как они влияют на решения.

А исходные варианты такие:
(1) либо это "продуктовая" разработка (в том числе с легким "допилом" на месте под конкретного кастомера) или это создания с нуля относительно "уникальных" приложений под конкретного заказчика;
(2) либо проект - это расширение стандартного функционала СРМ и иже с ним, или это никак не связанный с СРМ проект на базе форс.сом (хотя стандартный Эккаунт\Контакт может использоваться).

Вот те проблемы, которые я могу предложить для обсуждения:

(1) Process-centric App (как почти все на СФ): что используем для создания бизнес-логики: по-возможности используем поинт-энд-клик конфигурирование или все, все закладываем в код?

(2) Используем или не используем стандартные Эккаунт\Контакт в форс.сом приложениях? дело даже не в лицензии, а в том, что многие сущности можно отнести к категории Эккаунт, но не хочется все забивать их в стандартный Эккаунт, плодить бесконечные РТ для большого Орга...

ваши мысли, другие проблемные ситуации...

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

начну с двух примеров, но в самом начале предлагаю немного "раскидать" варианты исходных ситуации, так как они влияют на решения.

А исходные варианты такие:
(1) либо это "продуктовая" разработка (в том числе с легким "допилом" на месте под конкретного кастомера) или это создания с нуля относительно "уникальных" приложений под конкретного заказчика;
(2) либо проект - это расширение стандартного функционала СРМ и иже с ним, или это никак не связанный с СРМ проект на базе форс.сом (хотя стандартный Эккаунт\Контакт может использоваться).

Вот те проблемы, которые я могу предложить для обсуждения:

(1) Process-centric App (как почти все на СФ): что используем для создания бизнес-логики: по-возможности используем поинт-энд-клик конфигурирование или все, все закладываем в код?

(2) Используем или не используем стандартные Эккаунт\Контакт в форс.сом приложениях? дело даже не в лицензии, а в том, что многие сущности можно отнести к категории Эккаунт, но не хочется все забивать их в стандартный Эккаунт, плодить бесконечные РТ для большого Орга...

ваши мысли, другие проблемные ситуации...

1. Везде по максимуму пытаюсь использовать поинт энд клик. Стоимость работы имплементора существенно ниже стоимости работы девелопера. В код уходят только те вещи, которые трудно реализовать иначе.

2. По максимуму использую стандартные объекты и количество РТ вообще не смущает.

3. Сейчас моя головная боль Процесс Билдер. Вещь вроде удобная, но еще не обкатанная и очень много проблем с тестами.

1. Везде по максимуму пытаюсь использовать поинт энд клик. Стоимость работы имплементора существенно ниже стоимости работы девелопера. В код уходят только те вещи, которые трудно реализовать иначе.

2. По максимуму использую стандартные объекты и количество РТ вообще не смущает.

3. Сейчас моя головная боль Процесс Билдер. Вещь вроде удобная, но еще не обкатанная и очень много проблем с тестами.

По максимуму использую стандартные/встроенные иструменты.

По максимуму использую стандартные/встроенные иструменты.

Gres
По максимуму использую стандартные/встроенные иструменты.

Поддерживаю

[quote="Gres"]По максимуму использую стандартные/встроенные иструменты.[/quote]

Поддерживаю

По максимуму использую кастомные решения и без особой необходимости вообще стараюсь не касаться стандартного функционала.
Да, решение получается абсолютно не "поинт энд клик" зато все легко реализуется, кастомизируется и ни с чем не конфликтует. На первой конторе с одним пакетом построенным на стандартном функционале навидался таких костылей что больше не хочется с этим связываться.

По максимуму использую кастомные решения и без особой необходимости вообще стараюсь не касаться стандартного функционала.
Да, решение получается абсолютно не "поинт энд клик" зато все легко реализуется, кастомизируется и ни с чем не конфликтует. На первой конторе с одним пакетом построенным на стандартном функционале навидался таких костылей что больше не хочется с этим связываться.