Чи все-таки справедливо говорити про анемічну модель в контексті функціонального програмування?

Більшість моделей тактичного дизайну DDD належать до об'єктно-орієнтованої парадигми, а анемічна модель описує ситуацію, коли вся бізнес-логіка вводиться в сервіси, а не в об'єкти, таким чином робить їх своєрідним DTO. Іншими словами, анемічна модель - синонім процедурного стилю, що не рекомендується для складної моделі.

Я не дуже досвідчений в чистому функціональному програмуванні, але хотів би знати, як DDD вписується в парадигму FP і чи існує в цьому випадку термін «анемічна модель».

Оновлення : нещодавно опубліковані книги та відео з цього питання.

Те, як описана проблема "анемічної моделі", не відповідає успіху FP, як є. По-перше, це потрібно відповідним чином узагальнити. По суті, анемічна модель - це модель, яка містить знання про те, як правильно її використовувати, а не інкапсульована самою моделлю. Натомість ці знання поширюються навколо купи супутніх послуг. Ці служби повинні бути лише клієнтами моделі, але через анемію вони несуть відповідальність за неї. Наприклад, розглянемо Accountклас, який не можна використовувати для активації чи деактивації облікових записів або навіть пошуку інформації про обліковий запис, якщо не обробляється через AccountManagerклас. Обліковий запис повинен відповідати за основні операції над ним, а не якийсь зовнішній клас менеджера.

У функціональному програмуванні подібна проблема існує, коли типи даних не представляють точно те, що вони повинні моделювати. Припустимо, нам потрібно визначити тип, що представляє ідентифікатори користувачів. "Анемічне" визначення зазначає, що ідентифікатори користувачів - це рядки. Це технічно можливо, але виникає величезна проблема, оскільки ідентифікатори користувачів не використовуються як довільні рядки. Немає сенсу об'єднувати їх або вирізати їх підрядки, Unicode насправді не має значення, і вони повинні легко вбудовуватися в URL-адреси та інші контексти із суворими обмеженнями символів та форматів.

Вирішення цієї проблеми зазвичай відбувається в кілька етапів. Простий перший розріз - сказати "Ну, а UserIDпредставлений еквівалентно рядку, але вони різні типи, і ви не можете використовувати одне там, де очікуєте іншого". Haskell (та деякі інші набрані функціональні мови) надають цю функцію через newtype:

newtype UserID = UserID String

Це визначає UserIDфункцію , яка , коли задана Stringбудує значення, яке обробляє , якUserID система типу, але все ще тільки Stringпід час виконання. Тепер функції можуть оголосити, що вони вимагають UserIDзамість рядка; використання UserIDs, де ви раніше використовували захисні рядки проти коду, що об'єднує два UserIDs разом. Система типу гарантує, що цього не може відбутися, ніяких тестів не потрібно.

Слабкість в тому , що код все ще може приймати будь-яке довільне , Stringяк "hello"і побудувати UserIDз нього. Подальші кроки включають створення функції "розумного конструктора", яка при введенні рядка перевіряє деякі інваріанти і повертає лише те, UserIDякщо вони задоволені. Тоді "німий" UserIDконструктор стає приватним, тому, якщо клієнт хоче, UserIDвін повинен використовувати розумний конструктор, тим самим запобігаючи появі неправильно сформованих UserID.

Навіть подальші кроки визначають UserIDтип даних таким чином, що неможливо побудувати той, який неправильно сформований або "неправильний", просто за визначенням. Наприклад, визначення a UserIDяк списку цифр:

data Digit = Zero | One | Two | Three | Four | Five | Six | Seven | Eight | Nine
data UserID = UserID [Digit]

Для побудови UserIDсписку цифр необхідно надати. З огляду на це визначення, неправдиво показати, що UserIDіснування неможливо, яке не може бути представлене в URL-адресі. Визначення подібних моделей даних у Haskell часто допомагає розширеним функціям системи типу, таким як Data Data та General Algebraic Data Types (GADT) , які дозволяють системі типів визначати та доводити більше інваріантів щодо вашого коду. Коли дані відокремлюються від поведінки, визначення даних є єдиним засобом, який потрібно застосовувати до поведінки.

Значною мірою незмінність робить непотрібним тісно поєднувати свої функції зі своїми даними, як захисники ООП. Ви можете робити скільки завгодно копій, навіть створюючи похідні структури даних у коді, віддаленому від початкового коду, не побоюючись, що оригінальна структура даних несподівано зміниться з-під вас.

Тим НЕ менше, кращий спосіб зробити це порівняння, ймовірно , дивитися на які функції ви спрямовуєте до моделі шару по порівнянні з послугами шару . Незважаючи на те, що це виглядає не так, як в OOP, це досить поширена помилка в FP, щоб спробувати втілити те, що повинно бути декількома рівнями абстракції в одній функції.

Наскільки мені відомо, ніхто не називає це анемічною моделлю, оскільки це термін ООП, але ефект той самий. Ви можете і повинні повторно використовувати загальні функції, де це можливо, але для більш складних операцій або конкретних програм, ви також повинні забезпечити багатий набір функцій саме для роботи зі своєю моделлю. Створення відповідних абстракційних шарів - це хороший дизайн у будь-якій парадигмі.

При використанні DDD в OOP однією з основних причин розміщення бізнес-логіки в самих об'єктах домену є те, що бізнес-логіка зазвичай застосовується шляхом мутації стану об'єкта. Це пов’язано з інкапсуляцією: Employee.RaiseSalaryможливо, вимкнено salaryполе Employeeекземпляра, яке не повинно бути публічно встановленим.

У FP уникнути мутації, тому ви реалізуєте цю поведінку, створивши RaiseSalaryфункцію, яка приймає наявний Employeeекземпляр і повертає новий Employee екземпляр з новою зарплатою. Тож жодна мутація не бере участь: лише читання з оригінального об'єкта та створення нового об’єкта. З цієї причини таку RaiseSalaryфункцію не потрібно визначати як метод на Employeeкласі, але вона може жити де завгодно.

У цьому випадку стає природним відокремлення даних від поведінки: одна структура являє собою Employeeдані як повністю (анемічні), тоді як один (або кілька) модулів містять функції, які працюють на цих даних (зберігаючи незмінність).

Зауважте, що при поєднанні даних та поведінки, як у DDD, ви, як правило, порушуєте Принцип єдиної відповідальності (SRP): Employeeможливо, доведеться змінитись, якщо змінити правила зміни зарплат; але це може також знадобитися змінити, якщо змінити правила обчислення бонусу EOY. З підключеним підходом це не так, оскільки ви можете мати декілька модулів, кожен з яких несе відповідальність.

Отже, як звичайно, підхід ПЗ забезпечує більшу модульність / компонованість.

Я думаю, що суть справи полягає в тому, що анемічна модель з усією логікою домену в службах, що працюють на моделі, є в основному процедурним програмуванням - на відміну від "реального" програмування OO, де у вас є об'єкти, які "розумні" і містять не просто дані але й логіка, яка найбільш тісно пов'язана з даними.

І той же контраст існує з функціональним програмуванням: "справжній" FP означає використання функцій як першокласних сутностей, які передаються навколо як параметри, а також будуються на ходу і повертаються як повернене значення. Але коли ви не користуєтесь усією владою та маєте лише функції, які працюють на структурах даних, які передаються між ними, то ви опиняєтесь там же: ви в основному виконуєте процедурне програмування.

Я хотів би знати, як DDD вписується в парадигму FP

Я думаю, що це є, але багато в чому як тактичний підхід до переходу між незмінними об'єктами цінності або як спосіб запускати методи на сутність. (Там, де більшість логіки все ще живе в сутності.)

і чи все ще існує термін «анемічна модель».

Ну, якщо ви маєте на увазі "аналогічно традиційному OOP", це допомагає ігнорувати звичні деталі реалізації та повернутися до основ: Якою мовою користуються ваші доменні експерти? З якою метою Ви захоплюєте своїх користувачів?

Припустимо, що вони говорять про зв'язування процесів і функцій разом, то, здається, функції (або, принаймні, "виконайте" об'єкти) в основному є вашими доменними об'єктами!

Тож у такому сценарії "анемічна модель", ймовірно, може виникнути, коли ваші "функції" насправді не виконуються, а натомість є лише сузір'ями метаданих, які інтерпретуються службою, яка справді працює.