Понятие и применение Модели и моделирования в программировании с примерами на JavaScript и PHP, DDD

Привет, Вы узнаете о том , что такое модель в программировании, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое модель в программировании, моделирование в программировании , настоятельно рекомендую прочитать все из категории Моделирование информационных систем.

модель в программировании и DDD — это абстракция, описывающая предметную область, ее данные и поведение. В DDD модель — центральный элемент, отражающий бизнес-логику.

Вот подробное объяснение с примерами на JavaScript и PHP:

Что такое модель в программировании

В общем смысле модель — это структура, которая описывает данные и операции над ними. Она может быть частью архитектурных паттернов, таких как MVC (Model-View-Controller), где модель отвечает за:

• хранение данных,

• бизнес-логику,

• взаимодействие с базой данных.

В DDD термин модель имеет особый смысл:

Модель = формализованное представление предметной области в коде.

Поэтому:

• Entity

• Value Object

• Aggregate

• Domain Service

• Domain Event

— все это элементы доменной модели (domain model).
То есть они составляют модель предметной области, но сами по себе не являются “моделями ORM” или “Model из MVC”.

Где используется понятие «модель»

User 
Order 
Account 
Character (в игре)

class Car: 
def __init__(self, brand, year): 
   self.brand = brand 
   self.year = year 

def drive(self): 
    print("Driving")

Класс = инструмент (форма) 
Модель = смысл (содержание) 

Пример на PHP (MVC):

class Product {
    public $name;
    public $price;

    public function __construct($name, $price) {
        $this->name = $name;
        $this->price = $price;
    }

    public function applyDiscount($percent) {
        $this->price -= $this->price * ($percent / 100);
    }
}

Пример на JavaScript (MVC):

class Product {
  constructor(name, price) {
    this.name = name;
    this.price = price;
  }

  applyDiscount(percent) {
    this.price -= this.price * (percent / 100);
  }
}

Модель в Domain-Driven Design (DDD)

В DDD модель — это не просто структура данных, а отражение бизнес-реальности. Об этом говорит сайт https://intellect.icu . Она включает:

• Сущности (Entities) — объекты с уникальной идентичностью.

• Значения (Value Objects) — объекты без идентичности, определяемые по значению.

• Агрегаты (Aggregates) — группы связанных сущностей.

• Сервисы домена — операции, не принадлежащие конкретной сущности.

Пример на JavaScript (DDD):

class Order {
  constructor(id, items) {
    this.id = id;
    this.items = items;
  }

  getTotal() {
    return this.items.reduce((sum, item) => sum + item.price * item.quantity, 0);
  }
}

class Item {
  constructor(name, price, quantity) {
    this.name = name;
    this.price = price;
    this.quantity = quantity;
  }
}

Пример на PHP (DDD):

class Order {
    private $id;
    private $items = [];

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

    public function addItem(Item $item) {
        $this->items[] = $item;
    }

    public function getTotal() {
        $total = 0;
        foreach ($this->items as $item) {
            $total += $item->getPrice() * $item->getQuantity();
        }
        return $total;
    }
}

class Item {
    private $name;
    private $price;
    private $quantity;

    public function __construct($name, $price, $quantity) {
        $this->name = $name;
        $this->price = $price;
        $this->quantity = $quantity;
    }

    public function getPrice() {
        return $this->price;
    }

    public function getQuantity() {
        return $this->quantity;
    }
}

Применение модели в DDD

• Фокус на бизнес-логике, а не на технической реализации.

• Единый язык между разработчиками и бизнесом.

• Разделение ответственности: модель не зависит от UI или базы данных.

• Упрощение сложных систем через агрегацию и контексты.

1. Value Objects

Объекты без идентичности, определяются только значением.

Признаки:

• неизменяемые

• сравниваются по значениям

• не живут сами по себе

Пример:

Money (amount + currency) 
Email 
Coordinates 
Damage 

2. Агрегаты и Aggregate Root

Группа связанных объектов, которые изменяются только через корень агрегата.

Пример:

Order (Aggregate Root) 
├─ OrderItem 
├─ DeliveryAddress (Value Object) 

Правило:

снаружи можно работать только с Aggregate Root

3. Доменные сервисы (Domain Services)

Логика домена, которая не принадлежит одной сущности.

Пример:

DamageCalculator
PaymentPolicy
MatchmakingService 

4. Доменные события (Domain Events)

Факты, которые уже произошли в домене.

Пример:

OrderPaid UserRegistered BossDefeated 

Что НЕ является моделью в DDD

DTO
ORM-модели как «мешки с полями»
Контроллеры
Репозитории (они обслуживают модель, но не входят в нее)

Главное отличие от «обычного ООП»

В Domain-Driven Design (DDD) модель — это не просто набор классов с методами. Она — отражение бизнес-реальности, и с ней можно делать гораздо больше, чем просто вызывать ее собственные методы. Вот что можно делать с моделью вне ее внутренней логики:

Что можно делать с моделью в DDD, кроме ее собственных методов

1. Интеграция с другими моделями

• Связывать модель с другими агрегатами через доменные события или сервисы.

• Пример: заказ (Order) может инициировать создание счета (Invoice) через доменный сервис.

2. Валидация и инварианты

• Проверять модель на соответствие бизнес-правилам.

• Пример: проверка, что сумма заказа не превышает лимит клиента.

3. Использование в доменных сервисах

• Вынесение операций, не принадлежащих конкретной сущности, в отдельные сервисы.

• Пример: расчет скидки по сложной формуле, зависящей от внешних факторов.

4. Сериализация и хранение

• Преобразование модели в JSON, XML, SQL и другие форматы для хранения или передачи.

• Пример: сохранение заказа в базе данных или отправка по API.

5. Отслеживание изменений (Audit / Event Sourcing)

• Запись изменений модели в виде событий.

• Пример: логирование каждого изменения статуса заказа.

6. Проверка бизнес-правил через спецификации

• Использование паттерна Specification для проверки условий.

• Пример: IsEligibleForDiscountSpecification проверяет, подходит ли заказ для скидки.

7. Отображение в UI через DTO или ViewModel

• Преобразование модели в удобный формат для отображения.

• Пример: OrderViewModel показывает только нужные поля заказа.

8. Тестирование модели

• Юнит-тесты, проверяющие поведение модели в разных сценариях.

• Пример: тест, что метод applyDiscount() не дает отрицательной цены.

Пример: модель + доменный сервис на PHP

class OrdertService {
    public function calculate(Order $order): float {
        if ($order->getTotal() > 1000) {
            return $order->getTotal() * 0.1;
        }
        return 0;
    }

    public function save(Order $order): float {

... }

Пример: модель + сериализация на JS

const order = new Order(123, [new Item("Book", 20, 2)]);
const json = JSON.stringify(order); // можно отправить по API

моделирование в программировании

Моделирование в программировании — это процесс создания абстрактного представления реальной системы или процесса, чтобы понимать, анализировать, прогнозировать или воспроизводить поведение этой системы.

Или если проще: мы создаем модель, чтобы проверить идею, изучить поведение или спроектировать систему до ее реальной реализации.

Основные цели моделирования

• Понимание системы
  Разобраться, как что-то работает.

• Прогнозирование
  Узнать, как система будет вести себя при определенных условиях.

• Оптимизация
  Найти лучший способ построить систему или решить задачу.

• Тестирование идей без риска
  Проверить гипотезу, не строя реальный объект.

Где используется моделирование в программировании

Инструменты моделирования

• UML диаграммы (классов, состояний, последовательностей)

• SysML для сложных систем

• ER-диаграммы для баз данных

• Симуляторы (MATLAB, Simulink, Unity физика, PySim)

• Алгоритмические модели (функции, структуры данных)

Алгоритмы компьютерного моделирования

• Метод конечных элементов
• Метод конечных разностей
• Метод конечных объемов
• Метод подвижных клеточных автоматов
• Метод классической молекулярной динамики
• Метод компонентных цепей
• Метод узловых потенциалов

Важно не путать

Модель — это результат.
Моделирование — это процесс создания модели.

Пример простой модели (программистской)

class Car: 
def __init__(self, speed, fuel):
   self.speed = speed 
   self.fuel = fuel 
def drive(self, distance): 
   self.fuel -= distance * 0.1 

Здесь Car — модель автомобиля.

Если же мы проектируем, как машина будет двигаться, какую физику использовать, как расходовать бензин — это уже моделирование.

Итог

• Моделирование — это процесс проектирования и анализа системы

• Модель — результат: абстракция, которую можно использовать в коде

• Используется в планировании, анализе, симуляциях, проектировании архитектуры

Интересные вопросы

1. если по логике нужно использовать трансакции при сохранении в бд где их нужно использовать в моделе, в репозитории слое или на сервисном слое или еще гдето?

Ответы

1 Транзакции в DDD должны управляться на уровне Application Service (сервисного слоя), а не внутри доменной модели и не внутри отдельных репозиториев.

Почему именно сервисный слой

В DDD есть четкое разделение ответственности:

Транзакция — это технический механизм согласованности, а не бизнес-правило.
Поэтому ей не место в доменной модели.

Правильный поток выполнения

Типичный use-case в DDD:

Application Service 
├── открыть транзакцию 
├── получить агрегат из репозитория 
├── вызвать бизнес-метод агрегата 
├── сохранить агрегат через репозиторий 
└── закоммитить транзакцию 

Пример (псевдокод)

class OrderApplicationService
 { 
public function payOrder(OrderId $orderId, Money $amount) 
{ 
$this->transactionManager->begin(); 
try
 { 
$order = $this->orderRepository->getById($orderId);
 $order->pay($amount); // бизнес-логика в домене
 $this->orderRepository->save($order); 
$this->transactionManager->commit(); 
} catch (\Throwable $e) { 
$this->transactionManager->rollback();
 throw $e; 
} 
} 
} 

Почему нельзя делать транзакции в репозитории

Если транзакция внутри репозитория:

 saveOrder() 
 savePayment() 
 saveUser() 

то ты не сможешь гарантировать консистентность между несколькими агрегатами.

А в реальном use-case обычно:

изменяем несколько агрегатов 

значит транзакция должна охватывать весь use-case, а не одну операцию.

Почему нельзя делать транзакции в доменной модели

Домен:

• не должен знать про БД

• не должен знать про ORM

• не должен знать про транзакции

Иначе это уже не чистая доменная модель.

А как же Domain Events?

Частый вопрос.

Правильная схема:

1. доменная модель генерирует события

2. они собираются в агрегате

3. после commit транзакции — публикуются

Это обычно делается в Application Service или в infrastructure-слое.

Особый случай — один агрегат

Если use-case работает строго с одним агрегатом, то:

одна транзакция = один агрегат

Это идеальная ситуация в DDD (Aggregate boundary = transaction boundary).

Итог

Транзакции открываются в Application Service
Репозитории — не управляют транзакциями
Доменная модель — ничего не знает о транзакциях
Одна транзакция = один use-case

Ментальная модель

Запомнить можно так:

Application Service = режиссер сценария

он решает:

• когда начать транзакцию

• какие агрегаты загрузить

• какие методы вызвать

• когда сохранить

• когда коммитить

Вау!! 😲 Ты еще не читал? Это зря!

• модель
• моделирование
• ООП
• класс
• класс , виды классов ,
• объектно-ориентированный подход к разработке по , объект ,
• объект в программировании , объект в ооп ,
• паттерны проектирования классов , паттерны проектирования объектов ,
• объектно-ориентированное программирование , ооп в php ,
• диаграммы классов ,
• основные принципы разработки классов и объектов , разработка классов ,
• Время жизни объекта
• Клонирование объекта
• Шаблон проектирования (информатика)
• Бизнес - объект ( информатика )
• Актерская модель

Исследование, описанное в статье про модель в программировании, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое модель в программировании, моделирование в программировании и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Моделирование информационных систем

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.