Anemic Domain Model [Переклад]

На тлі свого захопленого вивчення DDD, я прочитав статтю Мартіна Фаулера від 25 листопада 2003 Anemic Domain Model . Іноді для кращого розуміння матеріалу я перекладаю його на російську мову. Ось я і вирішив поділитися перекладом.
Переклад авторський і місцями дуже смисловий.
 
Посилання на оригінал .
 
У статті є цитати з вже опублікованої книги, яка була перекладена на російську мову професіоналами, для того що б покращити розуміння мого перекладу я привів цитати з книги під спойлерами.

 
 
 Бліда Доменна Модель
 
Це один з тих анти-патернів який довгий час оточував нас, а зараз проявляється ще активніше. Я говорив про це з Еріком Евансом і ми обидва відзначили що він стає все популярнішим. І я як прихильник правильної доменну Моделі, вважаю що це не є добре.
 
 
 
Перші симптоми Блідої доменну Моделі це те що вона виглядає нормально, але тільки на перший взляд. Об'єкти іменування як іменники з предметної області, пов'язані між собою і мають структуру як у нормальних доменних об'єктів. Розуміння приходить при перегляді їх вмісту, воно навряд чи більше ніж набір геттеров і сеттерів. Часто ці доменні об'єкти приходять з архітектурними правилами не розміщувати будь-яку доменну логіку в них. Натомість є набір сервісів (сервісних об'єктів) які містять всю доменну логіку в собі. Ці сервіси знаходяться архітектурно рівнем вище доменної моделі і використовують її як джерело даних.
 
Весь жах цього анти-патерну в тому, що він йде врозріз з базовою ідеєю Об'єктно орієнтоване проектування, який складається а тому, що б поєднувати дані і процес (поведінка). Бліда модель це щось типу, процедурного проектування, якраз те, з чим такі фанати як я і Ерік, боролися з самих перших днів своєї роботи зі Smalltalk.
 
У наші дні Об'єктно Орієнтований пуризм це добре, але я вважаю що треба більше вагомих аргументів проти цієї «блідості» в моделі. Проблема Блідої доменну Моделі в тому, що вона несе всю нагруеку доменну Моделі не привносячи її переваг. А розплачуємося ми за це незграбністю маппінга бази даних, який зазвичай виливається в цілий шар ORM. Це має сенс тільки тоді, коли використовуються потужні Об'єктно Оріенірованние техніки для організації складної логіки. Однак переміщаючи все поводження системи в сервіси, треба розуміти, що все закінчиться погано Transaction Script 'ами, і ви звичайно втратите всі переваги, які несе Доменна Модель. Але як я говорив у книзі P of EAA Доменна Модель не завжди кращий вибір.
 
Також варто відзначити, що розміщення поведінки в Доменних об'єкт не повинно суперечити послідовному підходу використання шарів, для відділення доменної логіки від шару персистентності і уявлення. Логіка яка повинна бути в доменному об'єкті це і є доменна логіка, наприклад: валідація, розрахунки або все що ви називаєте «бізнес правила».
(Кінцеве є випадки коли ви через параметр передаєте в доменний об'єкт джерело даних або шматки логіки подання, але це ортогонально до моєму уявленню про «блідості».)
 
Одним з джерел невірного тлумачення є те, що багато Об'єктно Оріенірованние експерти рекомендують розміщувати шар процедурних сервісів над доменної моделлю, для того що б сформувати сервісний шар. Але це не аргумент не розміщувати поведінку в доменній моделі, насправді сервісний шар підштовхує до використання його у зв'язці з доменною моделлю містить поведінку.
 
Відмінна книга Еріка Еванса " Domain Driven Design " говорить следуйщій про цих шарах.
 
 
Шар додатки [так він називає Сервісний Шар]: визначає завдання які передбачається, що додаток буде вирішувати і направляє їх виконання на (багату) доменну модель. Завдання цього шару значимі для бізнесу (не бізнес логіка) або є просто взаємодією з прикладним рівнем інших систем. Цей шар повинен залишатися тонким. Він не містить бізнес логіки або будь-яких знань, він тільки координує завдання і делегує роботу наборам доменних об'єктів рівнем нижче. Він не несе стану яке відображало б ситуацію в бізнес логіці, але може знати про стан виконання завдання для інформування користувача і / або програми вцілому.
 
 
 З книги
Визначає завдання, які має вирішити завдання, і розподіляє їх між об'єктами, що виражають суть предметної області. Завдання, виконувані цим рівнем, мають сенс для користувача-фахівця або ж необхідні для інтерактивної взаємодії з операційними рівнями інших систем. Цей рівень не потрібно «роздувати» у розмірах. У ньому не містяться ні знання, ні ділові регламенти (business rules), а тільки виконується координування завдань і розподіл роботи між сукупностями об'єктів предметної області на наступному, більш низькому рівні. У ньому не відбивається стан об'єктів прикладної моделі, але зате він може містити стан, що інформує користувача про ступінь виконання завдання для інформування користувача.
 
 
 
 
Шар Домена (або Шар Моделі): Відповідає за подання сенсу бізнес процесів, несе інформацію про бізнес ситуації і бізнес правилах (бізнес логіці). Тут контролюється і використовується стан яке відображає ситуацію в додатку (в його бізнес частини), нехай навіть технічні деталі зберігання даних (персистентності) і делегуються інфраструктурі.
 Цей шар серце додатки.
 
 
 З книги
Відповідає за подання понять прикладної предметної області, робочі стану, ділові регламенти. Саме тут контролюється і використовується поточний стан прикладної моделі, нехай навіть технічні подробиці маніпуляцій даними делегуються інфраструктурі. Цей рівень є головною, алгоритмічної частиною програми.
 
 
 
Сенс тут в тому що Сервісний Шар тонкий , а вся логіка знаходиться в шарі Домена. Він (Ерік) повторює це в його сервісному шаблоні
 
 
Зараз загальна помилка, здаватися занадто рано при приміщенні поведінки у відповідний об'єкт, поступово скочуючись у процедурне програмування.
 
 
 З книги
У цьому місці легко здійснити поширену помилку: відмовитися від спроби помістити операцію в відповідний для неї об'єкт, і таким чином прийти до процедурного програмування.
 
 
 
Я не знаю чому цей анти-патерн так часто зустрічається. Я підозрюю це від того, що так багато людей які не працювали з правильної доменної моделлю, особливо якщо вони прийшли зі світу даних. Деякі технології заохочують цей анти-патерн, такі як J2EE'шние Entity Beans, це одна з причин чому я волію POJO доменні моделі.
 
Загалом чим більше вашої логіки в сервісах, тим більше схоже на те що, ви залишили себе без переваг доменну Моделі. А якщо вся ваша логіка в сервісах, то ви тупо себе обібрали.
 
 
Спасибі за увагу.
 
На інвайт не претендую, так як він мені не потрібен. Але якщо хтось думає, що матеріал вартий инвайта, просто дайте знати в коментарях, мені буде приємно.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.