Ильдар Н

Что именно мешает определиться? Пробовал nextCloud, OwnCloud и Seafile.
Больше всего понравился Seafile. Показался стабильнее, быстрее, безопаснее (шифрование), ну и в нём нет ничего лишнего.

mike153: пробовал все варианты. Nextcloud - это форк Owncloud. По сути, одно и то же, хоть и NC считается более продвинутым и вообще вся опенсорсная тусовка туда ушла. Поэтому пишу о нём. Всё исключительно на правах IMHO. Плюсы:
- Самый главный - это работа с файлами именно в файловом варианте. То есть, если предположить, что "всё упало", вы можете подключить диск с рухнувшего сервера к любому линуксу и вытащить инфу из /var/www или где она там у вас храниться будет. Также можно подключать внешние хранилища, то есть, предположим, есть у вас на сервере папка с фильмами и музыкой - их можно просто подключить в NC.
- CardDAV, CalDAV из коробки.
Минусы:
- Тормозит всегда, рандомно, в любой момент времени. Независимо от того Apache или Nginx, MySQL или MariaDB, тормозит на любом софте.
- Интерфейс - УГ, ШГ

Теперь о Seafile. Плюсы:
- Турбореактивный просто. Работает очень быстро.
- Интерфейс очень приятный.
- Продвинутое версионирование.
- Умеет открывать docx, odt, xlsx и т.д. без дополнительного софта. Но без редактирования. Если нужно редактирование - нужен отдельный Document Server от Collabora или Onlyoffice.
- PRO-версия бесплатна для 3-х пользователей, но смысла особого нет, т.к. enterprise-фишки заключаются в 1. полнотекстовому поиску по документам с помощью elasticsearch, у которого просто чудовищное потребление ресурсов 2. двух-факторной авторизации 3. и что-то там ещё, не особо нужное дома
- Есть клиенты для всех основных платформ
- Устанавливать можно как вручную по мануалу на сайте, так и воспользовавшись установочным скриптом, который сам всё сделает.
Минусы:
- Файлы хранятся в собственном формате, как это правильно называется? - на уровне блоков, что ли. Доступ к инфе только через веб-интерфейс, WebDAV, ну и приложения для синхронизации. То есть, вся информация в Seafile на диске представляет просто кучу мала из папок и файлов, которые нельзя так просто взять и использовать - нужен ещё дамп базы данных. То есть, в случае проблем с системой, достать информацию будет затруднительно. Но выход есть - seaf-cli - это безгуёвый клиент для синхронизации. Смысл в том, что на сервере, на котором крутится Seafile, дополнительно можно установить seaf-cli, натравить его на директорию, и он в эту самую директорию будет складывать синхронизированную копию инфы основной базы Seafile, причём в виде нормальных файлов, которые можно расшаривать как угодно, бэкапить и т.д. Минус решения с seaf-cli в том, что нужно вдвое больше дискового пространства для хранения инфы.
- Ну и как следствие такой организации файлов - невозможность подключить внешние хранилища, в отличие от тёплого лампового Nextcloud.

В общем, лично я остановился на Seafile.

1. Единственное отличие в том, что Subscriber определяет сразу несколько слушателей.
2. С помощью Subscriber'а удобно подписываться сразу на несколько событий одного класса. Например, Doctrine - можно сразу подписаться на postPersist и postUpdate и зарегистрировать один Subscriber. Если это же делать через Listener, то придется для каждого события создавать свой Listener и отдельно регистрировать его.
3. Если вы зарегистрировали Listener/Subscriber через Service Container, то вызывать EventDispatcher вам не нужно. Если же вы хотите подписываться на события в runtime, то тогда да, вам придется вызывать EventDispatcher.

Мэт Зандстра - PHP. Объекты, шаблоны и методики программирования

https://www.ozon.ru/context/detail/id/5648968/

Начать неплохо бы с понимания того, что такое DI. Обратимся к википедии:

Внедрение зависимости (англ. Dependency injection, DI) — процесс предоставления внешней зависимости программному компоненту.

Если выражаться не канцеляритом, а обычным русским языком, то DI - это когда вы своему компоненту (например, классу) предоставляете нужные для него зависимости извне, а не создаете их сами в конструкторе, или через инициализацию в месте объявления поля. То есть не так:

public class Api {
	....
	private final HttpClient client = new OkClient();
}

А, например, так:

public class Api {
	....
	private final HttpClient client;

	public Api(@NonNull HttpClient client) {
		this.client = client;
	}
}

И что нам это даёт?

Ну, очевидно, нам теперь проще менять зависимости. Нужна вам другая реализация абстрактного класса HttpClient - взяли, и передали её через конструктор, или через метод-setter. В случае с первым куском кода, вам пришлось бы ещё и класс Api переписывать, что в случаях, отличных от тривиальных, может привести к ошибкам. Получается, что ваш класс теперь закрыт от изменений (смотрим Open/Closed Principle).

Окей, а на практике-то какие бенефиты?

Во-первых, вы теперь можете написать инициализацию вашей программы через конфигурационные файлы. Скажем, на старте будет читаться простенький текстовый файл, который определяет, какой httpclient использовать, какие настройки доступа к бд применять и так далее, и, исходя из этого, будут определяться зависимости.
Во-вторых, вам теперь существенно проще писать тесты. Написали вы, скажем, какой-нибудь парсер, который принимает InputStream, содержащий в себе данные json-объекта, как-то хитро его парсит, и выдаёт вам объект вашей бизнес-модели. В приложении этот парсер будет принимать на вход реализацию InputStream'а, которая берёт данные из сети, а в тестах - реализацию, которая просто читает файл с диска (потому что тесты должны выполняться часто и быстро, и ваша задача в тесте - протестировать ваш парсер, а не скорость сетевого соединения).

Вот, в общем-то, и всё. А Dagger - это просто библиотека, которая автоматизирует ручное внедрение зависимостей, равно как и другие DI-библиотеки.

P.S. В некоторых случаях чрезмерное увлечение DI может привести к нежелательным эффектам, вроде чрезмерного усложнения кода, поэтому внедряйте аккуратно. Понимание приходит с опытом.

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

Тут не совсем модели. 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 раз больше, чем кода.
  
• Жесткие, обязательные кодревью.
  
• Если задача крупная - декомпозируйте ее.
  
• Технический долг - возвращайте обязательно И как можно скорее.
  
• Перед тем как писать код для работы с внешним сервисом - имеет смысл написать его эмулятор.
  
• Спешите только в случае серьезных проблем на проде)). Фичи "на вчера" отличаются от фич "на потом" только приоритетом выполнения, более ничем.
  

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

Раскидываю по неймспейсам. Скажем все действия относящиеся к юзерам находятся в папке Users.

Только вы учитывайте что CQRS это прикольно но особо не нужно. К примеру это сразу подразумевает что вы используете UUID вместо автоинкрементов и прочей чуши. Можете сделать хотя бы как Дядя Боб предлагает в своей Clean Architecture. Просто сервис на каждое действие.

Есть ли смысл выносить каждую доменную модель в модуль/микросервис

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

Раньше для дополнительных действий мне достаточно было использовать что-то вроде beforeUpdate/afterCreate модели.

ну а сейчас вы будете эти вещи в сервисы пихать. Причем возможно не в один сервис. Вообще старайтесь не делать "хуков" и не будет с ними проблем. Есть к примеру DomainEvents такая штука, ну и можно все эти "дополнительные действия" в хэндлерах команд делать.

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

Просто забудьте об этих ивентах.

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

Есть в симфони security vouters, а дальше все зависит от того что вы делаете.

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

git + docker теги в мастере. Ветки нужно плодить только тогда, когда у вас система деплоится кастомерам и нужно поддерживать сразу кучу версий. Называется это gitflow.

На какие проекты (точнее, на код) можете посоветовать посмотреть для лучшего понимания? Ссылки на репозитории?

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

p.s. почитайте книжки:

- Эрик Эванс - Предметно ориентированное проектирование
- Крэйг Ларман - Применение UML 2.0

p.p.s. Все ваши загоны не имеют никакого смысла если вы не будете пользоваться практиками вроде Test-Driven-Development, ну или хотя бы покрывать систему интеграционными тестами. Без этого вы не сможете делать частный мелкий рефакторинг, а без этого ваша система быстро превратится в легаси.

Ну давайте я покритикую:

возьмем файлик

1) вы не разобрались как объявлять методы у прототипов с новой нотацией `class`:

class Travelsort {
    constructor() {}
    sortTickets(tickets) {}
}

2) вы не умеете пользоваться исключениями.

if (!Array.isArray(cards)) {
    throw new ValueError('Wrong input');
}

3) использование let там где должен использоваться const

4) в принципе использование переменных там где их быть не должно

5) вы зачем-то реализовали свою функцию сортировки, я не увидел в требованиях отсутствия возможности использовать старый добрый Array.prototype.sort

6) Общие замечания по кодинг стайлу. snake_case там где должен быть camelCase, пишите с большой буквы то что должно быть с маленькой и т.д.

7) нарушения принципа единой ответственности. У вас объеткт умеет и сортировать и писать куда-то. Это категорически плохо.

8) Если исправить 7-ой пункт то наш класс превращается просто в функцию.

Далее... берем следующий файлик

1) если вы пишите комментарии к таким маленьким кускам кода - стало быть у вас хромает именование вещей. Все должн быть понятно просто из названий методов/функций/переменных. При работе в команде над серьезными проектами это немаловажно, ибо код чаще читают чем пишут и экономить нужно именно это время.

2) вы зачем-то тут в прототип объекта строки впихиваете функции для парсинга CSS. Таким образом мы нарушаем принцип единой ответственности. Да и в целом расширять без надобности прототипы объектов как-то не ок.

Чуть дальше проскролил - вы пытаетесь расширить прототип строк для того что бы добиться API jquery? ух, батенька.

3) очень много дублирования.

4) очень плохо с protected variations.

Справедливости ради, ваш код входит в категорию ">50% JS кода", так что не расстраивайтесь. Просто для работы в яндексе нужен чуть более высокий уровень и понимание вещей.

https://unsplash.com/ - природа, пейзажи и разные спокойные фото. Изображений очень много и все они высоком разрешении;
getrefe.tumblr.com - здесь меньше контента, но есть альтернативные категории;
www.splitshire.com - более серьёзная альтернатива предыдущему сайту;
https://picjumbo.com/ - кроме кучи качественных фото есть фича встраивания изображения в разные шаблоны для демонстрации. Для веб дизайна и верстки самое оно.

Контейнеры данных

Они не нужны, используйте named volumes вместо этого (с версии 1.9 докера).

Исходный код и локальные npm-модули (или лучше это в предыдущий контейнер, и при старте выполнять

Нет, npm install надо выполнять ДО сборки образа. Когда контейнер стартует - внутри у него уже все должно быть. Опять же я лично против того, что бы выносить исходники проекта в отдельный контейнер-пустышку. У вас есть контейнер с нодой - исходники для ноды должны быть там. Есть некоторые нюансы связанные со сборкой контейнера но это так.

На файловой системе хоста

Ничего.

Логи прокидываются в stdout/stderr контейнера и собираются на хосте через докер любым подходящим драйвером (читаем документацию).

Конфигурация - все что в конфигах от окружения к окружению меняется - в ENV переменные. Все остальное - не меняется и потому просто вшито внутрь контейнера.