Есть группа людей которые не понимают в программировании ничего, но у них есть идея, понимание как работает продукт, и деньги (но это вторично)
Назовем эту группу людей бизнес

Продукт этого бизнеса - сайт новостей. Возьмем как пример сайт новостей, потому что это по сути тот же блог.
Есть программист который понимает как автоматизировать действия этой идеи и оцифровать поведение продукта

Сначала бизнес описывает боль которую решает продукт
В чем боль? Бизнес раньше продавал газеты, а теперь хочет свою интернет газету.
1. Они не хотят тратить деньги на печать, а просто делать посты новостей и статьи.
2. Они не хотят платить деньги на транспортные расходы развозить газеты, а делать рассылки на электронную почту
3. Они хотят получать обратную связь (комментарии)
этого достаточно для примера.

В идеале бизнес заказывает дизайн. Как это должно выглядеть.
В идеале есть еще и пордакт менеджер который знает UML, но это влажные фантазии, по этому примем что есть бизнес и есть программист.

Затем описываются сущности этого продукта и действующие лица в этом продукте
Что мы можем понять из этого? Какие у нас есть сущности?
1. пост - новость или статья на сайте.
1.1. На этом этапе выясняем у бизнеса в чем отличие новости от статьи.
Бизнес говорит: у новости (например) есть только одна картинка, текст.
У статьи есть так же текст но картинок может быть несколько, так же не может быть комментариев.
Бизнес забыл про то что в дизайне есть еще и дата, тут уже додумывает сам программист взглянув на макеты.
В итоге у нас получается одна абстрактная модель Post и две ее реализующие: Article и News.

public abstract class Post
    {
        protected Post(string text, int writerId)
        {
            Text = text;
            CreationDate = DateTime.Now;
            WriterId = writerId;
        }

        public int Id { get; set; }
        public string Text { get; private set; }
        public DateTime CreationDate { get; private set; }
        //Идентификатор писателя статьи\новости
        public int WriterId { get; private set; }

        //Автоматически подтягиваемая из базы модель писателя через ORM по WriterId
        public virtual Writer Writer { get; set; }

    }

    public class Article : Post
    {
        public Picture[] Pictures { get; private set; }

        public Article(string text, int writerId, Picture[] pictures) : base(text, writerId)
        {
            Pictures = pictures;
        }
    }

    public class News : Post
    {
        public Picture Picture { get; }
        
        //Массив комментариев к посту
        // private set -- говорит о том что массив инкапсулирован
        // и управлять массивом можно только через метод AddComment
        public List<Commentary> Commentaries { get; private set; }

        public News(string text, int writerId, Picture picture) : base(text, writerId)
        {
            Picture = picture;
        }

        public void AddComment(Commentary commentary)
        {
            Commentaries.Add(commentary);
        }
    }

Далее у нас есть ролевые модели и у каждого своя бизнес логика.
2. Подписчик - получатель новостей. Бизнес хочет что бы каждый зареганый юзер автоматически стал подписчиком. Такого в реальном мире не будет, нельзя, но для примера норм.
3. Писатель - тот кто пишет статьи\новости.

Две эти модели отличаются между собой только ролью и наличием у подписчика поля email. По этому приведем вот такие ООП модели

public abstract class User
    {
        public int Id { get; set; }
        public string Username { get; private set; }
        public string Role { get; private set; }
        
        protected User(string role, string username)
        {
            Role = role;
            Username = username;
        }
    }

    public class Subscriber : User
    {
        public string Email { get; private set; }
        
        public Subscriber(string username, string email) : base(nameof(Subscriber), username)
        {
            Email = email;
        }
    }

    public class Writer : User
    {
        public Writer(string username) : base(nameof(Writer), username)
        {
        }
    }

Поле пароль опущено, тут много чего опущено для простоты восприятия.

3. Комментарий - обратная связь от юзера в посте. При чем хочу заметить от ЮЗЕРА, бизнес говорит что писать могут как и подписчик так и писатель

public class Commentary
    {
        public int Id { get; set; }
        public string CommentText { get; private set; }
        public int UserId { get; private set; }
        
        public virtual User User { get; private set; }
        
        public DateTime CommentCreationDate { get; private set; } 
        
        public Commentary(int userId, string commentText)
        {
            UserId = userId;
            CommentText = commentText;
            CommentCreationDate = DateTime.Now;
        }
    }

Вот - хоть и примитивно и немного неправильно (а то щас налетят пет программисты) но мы описали модели, абстрагировали одинаковые поля в абстрактные классы. Инкапсулировали поля и добавили методы которые описывают как работает класс. Инициализация полей происходит только в конструкторах. Работа с полями только с предоставленными для этого методами.

Прошу прощения что не PHP, но C# тоже C подобный, так что проблем с чтением на уровне моделей быть не должно.

Одна из функций ООП -- что бы программисты понимали бизнес.
Ну и человеку прозе описывать поведение реального мира объектами и как эти объекты между собой взаимодействуют.
Есть целые методологии разработки ПО такие как DDD, где вообще ядро кода пишется на копароративном языке и жестко соблюдаются правила названия моделей и описания алгоритмов бизнес процессов бизнеса. Код получается самодокументированным. Были случаи когда ядро по DDD писали даже на русском, потому что бизнес большой, а новичкам, кто приходил кодить в фирму, было быстрее и проще вкатиться в понимание прикладной практики бизнеса и понять по коду как бизнес устроен на разных слоях.

Я как делал:
Купил справочник c# толстенный.
Читаешь первые 4 главы как там советуют, въезжаешь, переписываешь код, понимаешь как устроен язык и синтаксис в принципе

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

Тупо копипастишь код лишь бы заработало.

Потом смотришь непонятные блоки кода. Что не понял - лезешь в справочник и читаешь как это устроено и работает, где то исправляешь ошибки свои.

Далее наращиваешь боту функционал. Например показывать погоду используя сторонние сервисы, там уже поймёшь как работать с API сторонних сервисов.

+ Раз в день читаешь главу, не особо стараясь вникать. Зачем? А затем что когда в жизни столкнешься с проблемой, вспомнишь примерно как это решать и в какую сторону гуглить.

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