MegaMufa

Комментарии в коде бесполезные, только глаза мозолят:

index: function (settings) {
    // Метод контроллера index
....
create: function (settings) {
    // Метод контроллера create
....

Если уж вы описываете свой код - делайте это с умом, посмотрите какие есть средства для генерации документации, например JSDoc

Используйте фигурные скобки и отступы везде, где только можно. Я, разумеется, понимаю, что "стильно модно молодежно" писать if в одну строку, но такого рода конструкции взрывают мозг:

....
else data = settings;
if (typeof data !== "string") data = $.param(data);
if (method == 'post') return $.post(url, data + '&_method=' + method_hidden);
else return $.get(url, data);
....

И, если еще придираться, - пустые строки после объявления переменных, после if/else, и.т.д. улучшают читабельность.

Не используйте ключевые слова из es6 где попало:
class: '.jsgrid-container',

Есть некоторая непоследовательность - иногда вы выносите объявления всех переменных в начало функции, иногда нет. Имеет смысл определиться и использовать что-то одно.

Да, и киньте ссылку на codepen что-ли, а то в 500 строк кода ни разу не понятно работает ли там что-то (и что оно вообще делает). И к этому хочется добавить - посмотрите в сторону систем сборки (Grunt/Gulp/...)на ваш вкус - скорее всего эти 500 строк можно разбить на части поменьше, станет проще ориентироваться в происходящем.

Как хранить бизнес-логику чтобы модели не превратились в монстров из десятков тысяч строк?

Тут не совсем модели. Entity - это просто объект данных, умеет хранить их в себе и бросать исключения, если не правильные данные вставляете, все. Repository - умеет работать со своим Entity И БД.

БЛ находится в классах сервисах.

Читал про Command Bus где, если правильно понял, на каждое действие в системе – свой класс?

Вообще под каждое дествие - не обязательно, тут нужно руководствоваться здравым смыслом.

Как их организуете (их тогда будут сотни)?

Иерархически. Путь к классу должен быть "понимаем".

Есть ли смысл выносить каждую доменную модель в модуль/микросервис, хранить всю связанную логику где-то там внутри, а с остальными общаться по внешнему API?

Только в тому случае, если вы уже делали такие же проекты и в точности знаете максимально точно границы каждого домена. Иначе - не стоит. Делайте монолитную систему, а разделение на микросервисы - только по факту необходимости.

За ответы в клиентскую часть – отдельный сервис-фронтенд?

Если в "сервис" вы вкладываете понятие простого класса, умеющего форматировать ответы вашего проекта - мысль здравая.
Если ответы будут асинхронными (от сервера к другому) - имеет смысл выностить в отдельный клиентский класс.

Каков оверхед?

Ничтожный.

Используют ли такое на практике?

Да

Какие подводные камни?

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

Как не превратить кидание/получение событий типа PostBeforeEdit/PostBeforeEditHandler в "callback hell"?

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

Функционал "PostBeforeEdit/PostBeforeEditHandler" часто дешевле и проще вынести в сервис, но опять же руководствуйтесь здравым смыслом.

ACL Где храните указанную логику?

Если ACL будет не тривиальный - готовьте себя к тому, что он будет размазан по уровню контроллеров.

Какие структуры для описанного выше – best practice?

Если есть возможность привести к одноуровневому виду - сделайте. Если с точки зрения бизнеса может потребоваться иерархическая (не фиксированной вложенности) ACL - до последнего убеждайте, что это плохая идея, не повторяйте чужих ошибок.

В моём понимании это выглядит как куча трёхмерных кубов доступа "crud – group – entity – field", как это сделать более плоским пока только одна идея – делать кучу таблиц many-to-many.

Гибкая настройка вплоть до каждого поля 90% что не нужна. Если можно свести к понятию скопов прав - сделайте это.
Структуру можно предлагать только зная ваш проект.

Версионирование. Как вы версионируете подобные проекты?

Semver.

А если нужна "N-1" рабочая версия на продакшене?

Значит на прод попадает ваша версия с тегом "N-1"))

Есть ли смысл разделять версии в рамках единой кодовой базы проекта и как (неймспейсы, конфиг, модуль, что-то ещё)?

Храните яйца в отдельных корзинках. Если модуль развивается полностью отдельно и может быть вынесен как зависимость проекта в vendor - делайте.

И, самое главное – как всё это совместить?

• РУКОВОДСТВУЙТЕСЬ ЗДРАВЫМ СМЫСЛОМ
  
• Принимаете жесткие соглашения по правилам написания кода, например такие
  
• Постарайтесь убедить бизнес в том, что без покрытия кода автотестами будет дороже, нестабильней и дольше. + Пишите тесты. Если объем тестов в 4 раза больше кода, который они тестируют - это норм. У меня бывали случаи, когда для критичного функционала тестов было в ~16 раз больше, чем кода.
  
• Жесткие, обязательные кодревью.
  
• Если задача крупная - декомпозируйте ее.
  
• Технический долг - возвращайте обязательно И как можно скорее.
  
• Перед тем как писать код для работы с внешним сервисом - имеет смысл написать его эмулятор.
  
• Спешите только в случае серьезных проблем на проде)). Фичи "на вчера" отличаются от фич "на потом" только приоритетом выполнения, более ничем.
  

<div class="div">div</div>
<a href="#" class="close"> Закрыть </a>

var closeBtn = document.getElementsByClassName('close')[0];

closeBtn.addEventListener('click', function() {
    document.getElementsByClassName('div')[0].style.display = 'none';
});

"caret_style": "solid"
www.sublimetext.ru/documentation/preferences/caret...

Благодаря тому, что программирование, это не идеология, не мифология, а вполне себе прекладная научная дисциплина, вся терминология в нем изначально предельно точная и информативная. В любом термине (кроме некоторых маркетинговых мемов) обычно содержится почти полный ответ на вопрос: "а что это такое", для понимания которого не нужно ничего запоминать - достаточно анализировать слова и синтезировать смысл абстракции по аналогии с предметами реального мира :) Однако, есть два момента.

Первый: терминология исторически англоязычная и всяческие попытки переводов чаще вредят, чем помогают понять суть. (Мне, например, пришлось напрячь Гугл, чтоб удостовериться, что под "шлюзом" Вы действительно подразумеваете "pattern gateway", а не что-то там еще).
Второй: термины часто обозначают не конкретные сущности, а абстракции. (Если вдруг значения последних двух слов понятны только на уровне смутного ощущения, разберитесь, что они конкретно означают... абстракция - это не "нечто туманное и заумное", а совсем другое :) ) Соответственно, для толкования этих терминов нужно использовать абстрактное мышление. Как?

Например, для того же шлюза... шлюз бывает между двумя реками с разным уровнем... да, там есть выше - ниже. Однако, бывает между двумя отсеками космического корабля (хорошо - там все еще может быть разное давление), а бывает между толпой пассажиров в аэропорту и выходом к самолету (давление толпы?)... или, между локальной сетью и внешней, и т.д. Если задуматься, почему все это называют таким словом, легко понять, что суть понятия не столько в перепаде (уровней, давлений и т.д.), а, наверное, в том, что "это такое нечто, только через которое можно попасть/выйти из одного в другое". .. оно же, кстати, соответствует буквальному переводу слова "gateway" - "выход наружу"...

И - сюрприз(!) - именно в этом и заключается суть паттерна. А вот, для сравнения, его формальное определение: "Объект, который инкапсулирует доступ к внешней системе и ресурсу." Решайте для себя сами, что лучше - знать английский, запоминать такие определения или один раз понять смысл аналогии, только учтите, что у всех слов в определениях тоже есть совершенно конкретный, точный смысл, который нужно знать или уметь находить - иначе определение ничего не объяснит, а только еще больше запутает :)

Далее... как его "сделать в коде"? А фиг его знает! Как удобнее для проектируемой системы, так и делайте. Может, это будет один класс, может микросервис, а может вообще железяка на FPGA. Паттерн не дает никаких готовых рецептов (типа, взять три грузовика бетона, выкопать яму глубиной 5 метров и пр.) - он просто говорит, что чем всем частям системы "лазить наружу" как попало, лучше это дело сконцентрировать в одном месте. И, кстати, патерн не является "современным стандартом" и, вообще, стандартом! Это просто обобщенный опыт поколений разработчиков систем. Не более, чем соображение мыть руки перед едой... если зачем-то нужно, можно и не мыть, но если нет какой-то осознанной мотивации, то мыть в большинстве случаев - лучше :)

Идем дальше... интерфейс. Что это такое? Формочка с кнопочками и чекбоксиками? А может, разъем USB? А может, код на каком-нибудь ЯП? Что между всем этим общего? Да очень просто! Интерфейс, это набор правил и соглашений о том, как пользоваться какими-то функциями того, что предоставляет этот интерфейс :)

Вот и все! В ИТ-шной терминологии нет никакой магии и никакого сакрального смысла. Для понимания достаточно знать ТОЧНОЕ значение довольно небольшого количества слов и для любого непонятного термина всегда задавать два простых вопроса: "что это значит" и "почему", и находить на них ответы. И все туманное и странное быстро становится простым и понятным :)

Сначала посмотрите это видео(лучше вряд ли найдёте).
По работе с указателями/ссылками -- Герберт Шилдт, Базовый курс C++. Начиная с 6 или 7-ой главы в этой книге применяются указатели и ссылки и рассказывается, что это такое (почитайте с 6-ой главы(или 7, когда уж там начинается тема указателей) ещё парочку глав, автор начнёт в своих программах использовать указатели, поразбирайте код, который там представлен и сможете их правильно использовать). Очень всё понятно.
Это для закрепления
И это
И это
И это

Начните сперва с C++ как с более распространенного языка.

Как следить за ней

Чтобы работало, и утечек памяти не было, то есть более не нужные данные не занимали память.

как правильно работать с указателями/ссылками

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

Всегда писал на языках, использующих сборщик мусора. Естественно никогда не парился по поводу работы с памятью.

В них тоже бывают утечки памяти, но это частные случаи, например, при многопоточности.

Предстоит редактирование достаточно крупного интернет магазина

Вы ящик водки уже купили?

Добрый день,

Если Вам достаточно отобразить на UI какие-то модельки, то можно обойтись без биндингов: setText на Label/TextField/etc.
Если Вам нужно создавать/редактировать модельки, то у Вас все равно будет Controller/Presenter/ViewModel (Вы же не будете это делать в setOnAction(e -> {}) ).
В Controller/Presenter/ViewModel Вы можете создать свойства-обертки, используя:
1) JavaBeanStringPropertyBuilder (самый простой способ, но имя поля модельки хардкодится строкой).
2) BeanPathAdapter из jfxtras (более продвинутый вариант, но имя опять таки хардкодится).
3) Создать кучу SimpleFooBarProperty и заполнять их данными из модельки.
4) Создать кучу SimpleFooBarProperty, переопределив методы get/set:

private ObjectProperty date = new SimpleObjectProperty() {

@Override
public Date get() {
return model.getReservationDate();
}

@Override
public void set(Date newValue) {
if (model.getReservationDate() != null && model.getReservationDate().equals(newValue)) return;
model.setReservationDate(newValue);
fireValueChangedEvent();
}
};

При этом моделька хранится в Controller/Presenter/ViewModel и можно добавить метод setModel(), который будет заменять модельку.
Единственная проблема -- после вызове setModel() свойства не уведомят подписанные на них контролы, что произошло измнение. Для этого нужно вызвать метод fireValueChangedEvent, который protected, к сожалению.
Обойти эту проблему можно следующим образом:
1) Добавляем блок инициализации в переопределенное свойство:
{ allNotifiers.add(this::fireValueChangedEvent); }
2) В Controller/Presenter/ViewModel создаем
protected List allNotifiers = new ArrayList<>();
public void raiseAllPropertiesUpdate() {
allNotifiers.stream.forEach(Runnable::run);
}
3) В методе setModel() добавляем вызов raiseAllPropertiesUpdate().
Теперь при подмене модели каждое проперти уведомит подписанные на него проперти/контроллы об изменении.