Где взять реальные примеры кода использования ооп в веб-сервисах?
Есть группа людей которые не понимают в программировании ничего, но у них есть идея, понимание как работает продукт, и деньги (но это вторично)
Назовем эту группу людей бизнес
Продукт этого бизнеса - сайт новостей. Возьмем как пример сайт новостей, потому что это по сути тот же блог.
Есть программист который понимает как автоматизировать действия этой идеи и оцифровать поведение продукта
Сначала бизнес описывает боль которую решает продукт
В чем боль? Бизнес раньше продавал газеты, а теперь хочет свою интернет газету. 
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 писали даже на русском, потому что бизнес большой, а новичкам, кто приходил кодить в фирму, было быстрее и проще вкатиться в понимание прикладной практики бизнеса и понять по коду как бизнес устроен на разных слоях.
Берите фреймворк, по их документации учитесь на нем делать Блог или Доску объявлений Попутно разбираетесь что к чему и как. Потом пробуете без фреймворков реализовать что-то свое.