Відповідь на введення в проектування сутностей, проблеми створення об'єктів

Після прочитання статті Введення в проектування сутностей, проблеми створення об'єктів на хабре, я вирішив написати розгорнутий коментар про приклади використання Domain-driven design (DDD), але, як водиться, коментар виявився занадто великим і я вважав правильним написати повноцінну статтю, тим більш що питання DDD, на хабре і не тільки, видаляється мало уваги.
DDD
Рекомендую прочитати статтю про яку я буду тут говорити.
Якщо коротко, то автор пропонує використовувати білдери для контролю за консистентностью даних в сутності при використанні DDD підходу. Я ж хочу запропонувати використання Data Transfer Object (DTO) для цих цілей.

Читати далі →

Введення в проектування сутностей, проблеми створення об'єктів

При моделюванні такого поняття предметно-орієнтованого проектування як сутність можуть виникнути деякі складності, обумовлені бізнес-вимог або технічною частиною. Зокрема, іноді виникає складність із створенням об'єкта-сутності.

У даній статті описуються дві такі проблеми, і розглядається спосіб їх вирішення. Так само стаття підійде як введення в проектування сутностей. Для розуміння матеріалу знадобиться базове уявлення про предметно-орієнтованому проектуванні.

Читати далі →

Domain-Driven Design: стратегічне проектування. Частина 1



Здрастуйте, хабрапользователи! У цій статті мова піде про предметно-орієнтованому проектуванні програмного забезпечення з використанням, в першу чергу, стратегічних шаблонів.

Даний підхід використовував Он Вернон у своїй книзі «Реалізація методів предметно-орієнтованого проектування». Мета написання цієї книги: дати можливість розробникам здійснити політ на літаку DDD (в дитинстві автор часто подорожував зі своєю родиною на невеликих літаках). Вид з висоти дає більш широке уявлення про проблеми моделювання, не даючи застрягти в різних технічних деталях. Спостерігаючи ландшафт DDD таким способом, можна усвідомити переваги як стратегічного, так і технічного проектування. Докладніше – під катом!
Читати далі →

Знову про розробку на основі предметної області (Domain-Driven Design, DDD)

Введення

Занадто багато разів я зустрічав програми, про яких говорили, що у них є модель предметної області та додаток було спроектовано на основі це предметної області. Проте в дійсності все, що я бачив, було колекцією сутностей (я б навіть сказав DTO), мають купу властивостей без якої б то не було реальної логіки, пов'язаної з сутністю. Крім того, я можу знайти багато сервісів всіх видів, які містять барвисту суміш бізнес-логіки та/або інфраструктури. Якщо додаток ж використовує шину повідомлень (як NServiceBus, Mass Transit Bus або Azure Bus), то звичайно ж помітно, що якісь повідомлення передаються від одного модуля до іншого або кількох модулів. На жаль, листи часто мають дуже узагальнені назви, що містять слова «оновити», «змінити», «додати» або «видалити», і несуть велику кількість корисної навантаження — десятки різноманітних властивостей. Часто з назви повідомлення зовсім не очевидно, чи є воно командою або подією, і щоб визначити це, доводиться глибоко заритися в реалізацію.

Я щиро хотів би, щоб все написане вище було би перебільшенням або ж мало сенс тільки для «старих» програм, які розрослися і вийшли з-під контролю. Але сумна істина в тому, що це відноситься до багатьох нових проектів, навіть тим, яким лише кілька місяців від народження. Чому так відбувається? Звичайно, є багато різних причин: відсутність знань є однією з найбільш важливих.

Читати далі →