Паша Андреев

Проблема "админок" для любого фреймворка в том, что дальше CRUD'а и спизж... дизайна они уехать не могут.

Пусть статья и комментарии будут разными агрегатами. У комментариев будет свой домен.

Можно в контексте комментариев сделать свой класс статьи( Article ). Он даже не будет сущностью:

class Article {
  private UUID id;
  
  private CommentsRepository comments;
  
  ...
  
  public void function addComment(commentData: commentData) {
    this.coments.add(new Comment(this.id, commentData));
  }
}

В контексте комментариев не обязательно нужна статья - нужен только её идентификатор.
Также в контексте комментариев вовсе не нужны данные пользователя - только его идентификатор. Идентификаторы достаточно стабильная информация чтобы не бояться их шарить.

И да, в данном случае мы имеем дело просто с декомпозицией системы, к реальному DDD это мало отношения имеет, потому что domain-driven-design, он domain-driven за счёт того что конексты обсуждаются с бизнесом, а не придумываются разработчиком, в данном случае мы просто берём оттуда немножко терминологии потому что она уже стала довольно общей.

Также интересные книги по DDD. Они углубляют понимание ООП и позволяют на порядок поднять его уровень.

Вы не поверите, но я куда лучше стал понимать ООП, попробовав пописать на Haskell и Erlang. Попробуйте. Серьезно. Здесь найдете книжки и подробности по этим языкам.

В PHP сообществе вообще не развиты вопросы проектирования и архитектуры. Большинство лепит, что придумает. PHP изначально родился для примитивных homepage, вобрал в себя всю несерьезность, низкий порог входа и как следствие довольно слабое комьюнити, что часто становится объектом для шуток.

Искать ответы на вопросы проектирования и архитектуры нужно в Java. Например там почти каждый с самых азов слышал о де факто ставшей стандартом слоистой архитектуре, она же layered architecture, она же n-tier architecture и видел изображение похожее на это

Из которой нужно понять, что всю программу можно разделить на несколько слоев и зависимость между слоями должна быть направлена сверху вниз, но не наоборот. Таким образом, например фреймворк может быть инкапсулирован в presentation слой и в любой момент безболезненно заменен на другой, так как другие слои ничего о нем не знают. Вся бизнес-логика инкапсулирована в domain слой в виде plain old java object, который не зависит вообще не от чего, а также предоставляет интерфейсы (репозиториев например) для инфраструктурного слоя и только в этом слое фактически и будет тот самый настоящий ООП, который все так упорно пытаются найти. Никакого стороннего кода в бизнес-логике нет, а соответственно весь сторонний код можно в любой момент поменять, не трогая бизнес-логику вообще.

Для этого нужно открыть какую-нибудь книгу, где за руку проведут с нуля до конкретного приложения построенного с использованием этой архитектуры. Например Implementing domain-driven design, хоть эта книга и о DDD, но я уже говорил, что слоистая архитектура это де факто. С опытом, будет понятно, что в более простых приложениях количество слоев можно уменьшить, понимая на какой компромисс придется пойти, что иногда можно объединить domain и часть infrastructure и получить всем известный шаблон Active Record или вообще выбросить эти слои и получить шаблон transaction script, когда для решения просто не требуется что-то более сложное. Придет понимание, как можно начать с transaction script и в итоге постепенно катиться в сторону domain layer, через active record или не через active record если это когда-нибудь понадобится и тому подобное. Cтанет понятно, зачем, как и когда использовать патерны о которых написал Мартин Фаулер в своей книге Patterns of Enterprise Application Architecture.

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

по п.1 — делается черех веб-хук GIT
по п.2 — миграции также как и любые др файлы проекта передаются через GIT на продакшн-сервер
а вот чтобы их применить — нужно на продакшене их накатить
по. п3 — пароли индивидуально на сервере задаются, их нельзя пихать в GIT


Чтобы все автоматизировать по цепочке:
push → веб-хук → pull+migrate+composer update+npm install

Можно использовать полноценные инструменты для деплоя:
Deployer
Capistrano

Бертран Мейер - Объектно-ориентированное конструирование программных систем
Мэтт Вайсфельд - Объектно-ориентированное мышление
Грэди Буч - Объектно-ориентированный анализ и проектирование с примерами приложений

На вопрос из заголовка ответом будет "ТАУ для чайников"
На вопрос из комментария однозначного ответа не дам, ибо сам хотел бы его получить. Пока что вижу путь чтения всего, что понимается и дальнейших попыток синтеза всего, что интересно. Хотя есть много советских книг по проектированию тех или иных устройств, чаще всего военной направленности, где сначала даются линейные уравнения объекта а потом на их основе синтезируются регуляторы.

В вашем случае проще не читать

Удивительно, что никто ещё не упомянул Понедельник начинается в субботу.

В некотором роде Мы Замятина. И, конечно, Гиперболоид инженера Гарина.

Дэн Браун, Цифровая крепость

Почему вы все так спешите начать работать? Да еще и вместо обучения (каким бы оно ни было).

- У вас еще впереди лет 30-40 работы, большую часть жизни вам придется работать. Вероятность того, что вы все эти 30 лет будете работать в удовольствие далеко не 100%.
- Начиная работать на 2-3 года раньше вам не дает сильных преимуществ в перспективе. В практически любой работе гораздо более важна эффективность, а не просто сколько времени вы проработали на определенной должности. Т.е. проработав, например, 5 лет, всегда найдутся люди с меньшим опытом которую делают вашу работу эффективнее (быстрее, качественнее)
- годы обучения в ВУЗе для очень многих людей являются самыми счастливыми, а во многих случаях даже формируют фундамент всей оставшейся жизни: друзья, хобби, знакомства, связи, какие-то ключевые события. Сидя 8 часов в офисе в день на работе или в квартире на фрилансе вы все это упустите скорей всего.
- во время учебы у вас есть масса времени попробовать поработать в разных местах и сферах: backend, frontend, мобильная разработка, дизайн, попробовать заняться научной деятельностью, попробовать что либо вообще не связанное с IT. После нескольких лет работы вы только будете мечтать о таком, но времени и возможности сменить радикально сферу работы вы не сможете просто.

ps ну нахрена вам деньги в 17 лет? Машину купить? Бабу свою свозить в Европу? iMac за 100 тысяч купить? Это все вещи которые не стоят вашего времени как минимум 17 лет точно.

Почитайте заголовочные .h файлы хорошо структурированных opensource проектов. Я на Plan9 учусь.