OOP: Is it architecturally correct to do this?

Question

PHP

Hey!

Working in some systems, I often have to make selections from various sources (nosql database, external api (or some internal modules), etc.) and most often, the result of such selections is an array of parameters and values.

In large projects, I find it difficult to work with these arrays because of the many problems with it.

Therefore, I wrap all this data in objects:

For example:

I have a method of the module for working with orders, which returns an order by its identifier.
An order is a set of parameters of the order itself, its buyer, goods, etc.

When designing, I get the following:

<?php
class Order {
  private array $order_fields;
  private Buyer $buyer;
  private BasketItems $basket_items;

  public function __construct(array $order_fields, Buyer $buyer, BasketItems $basket_items) {
    $this->order_fields = $order_fields;
    $this->buyer = $buyer;
    $this->basket_items = $basket_items;
  }

  public function getId(): int { return $this->order_fields['order_id']; }
  public function getAmount(): float { return $this->order_fields['order_amount']; }
  public function getBuyer(): Buyer { return $this->buyer; }
  public function getBasketItems(): BasketItems { return $this->basket_items; }
}

class Buyer {
  private array $buyer_fields;

  public function __construct(array $buyer_fields) {
    $this->buyer_fields = $buyer_fields;
  }

  public function getId(): int { return $this->buyer_fields['id']; }
  public function getFullName(): string { return $this->buyer_fields['full_name']; }
  public function getPhone(): string { return $this->buyer_fields['phone']; }
}
// ...

As a result, at some level of the application, a selection occurs, and then all the necessary objects are created and embedded into each other. (By the way, what is the name of this application layer, and in whose area of ​​responsibility is this task?)

I am confused by the many classes that very rarely contain any business logic in themselves.
And their main task is most often to receive an array of data for the current entity in the constructor (sometimes a ready-made object is introduced, which was previously assembled in the same way), and returned through getters. Perhaps this is normal, as it should be? Or how is it architecturally correct to solve this?

Answer 1

Perhaps this is normal, as it should be? Or how is it architecturally correct to solve this?

This is fine. Faceless arrays become meaningful entities. Such code becomes easier to understand and maintain.
The approach you are using is called data transfer object (DTO). Widespread practice. DTO goes great with the immutability that you have in your classes.
The only claim is only to the total absence of comments. It would be nice to describe the classes and each parameter on the subject of what it means, why it is needed and where it can be used.

As a result, at some level of the application, a selection occurs, and then all the necessary objects are created and embedded into each other. (By the way, what is the name of this application layer, and in whose area of ​​responsibility is this task?)

It's called ORM. It is the responsibility of the ORM layer/framework.