Программирование, по своей сути, сводится к обработке данных. От расчета суммы покупки кассовым аппаратом в пятерочки, до вычислений, требуемых для моделирования физики сложных объектов современной мощной четырёх-с-половиной слотовой видеокартой.
Различия начинаются тогда, когда мы говорим о способах представления данных и их обработки.
Парадигма программирования - то, что определяет способ представления и обработки данных в программах.
Одной и первых популярных парадигм является процедурное программирование, оно подразумевает четкое разделение данных и поведений программы. Поведения называются процедурами или функциями, они не имеют собственных данных, процедуры и функции имеют свой контекст, но данные в него попадают либо извне, либо путем модификации данных, уже существующих в контексте. Такое разделение хорошо отражает топологию выполнения программ, мы имеем набор данных, которыми оперируем, и набор инструкций для их обработки, которые не содержат этих самых данных.
Объектно ориентированное программирование изобрели, поместив стек выполнения функций в динамическую память, это привело к тому, что контекст функции сохранялся от вызова к вызову. Это определение объекта с технической точки зрения – замыкание нескольких поведений на какой-то контекст данных.
Это определение ООП достаточно техническое, и скорее отображает топологию программы, её детали реализации. Есть разница между парадигмами программирования и механизмами их реализации, ООП и программированием с использованием объектов.
Всем вам должны быть известны основные принципы ООП. Инкапсуляция, сокрытие, полиморфизм, композиция. Инкапсуляция подразумевает то самое объединение данных и поведений, сокрытие подразумевает ограничение доступа к данным и поведениям объекта извне. Объединяя данные приемы мы получаем абстракции как способ представления данных.
Разница между этими подходами заключается в том, что в ООП мы не работаем с атрибутами объектов напрямую, а пользуемся их поведениями для реализации операций. Наши абстракции отражают объекты моделируемой системы и определяют поведения отражающие моделируемый объект.
Такое представление называют богатой моделью данных. Её суть заключается в том, что наши модели отражают и поведения которые с ними ассоциированы.
В таком случае, бизнес правила инкапсулируются в сущностях системы, содержащихся в доменном слое. Слой приложения же становится местом, где определены сценарии использования, использующие сущности.
При проектировании богатой модели данных, основной фокус ложится на проектирование домена приложения. Инфраструктурные моменты по типу персистенции данных, инструментов представления, итд становятся второстепенными, и не должны проникать в домен, нельзя подстраивать его под них.
Данная модель противопоставляется богатой, данные в ней представляются в виде «глупых» моделей, не имеющих сокрытых атрибутов и инкапсулированной логики, своего рода структуры, которые мы положили в кучу и назвали объектами.
Такая модель в основном является не моделью домена, а скорее объектным отображением реляционной структуры вашей базы.
Термин «анемия» был предложен Мартином Фаулером, и должен иметь явно негативный характер. Анемия модели значит то, что она не способна производить никакие действия, я лишь бессильно лежит и поддается на любые манипуляции производимые с ней извне.
При использовании анемичной модели данных, бизнес логика полностью инкапсулирована в слое приложения. Вся бизнес логика