Comments 7
Начали за здравие, закончили за упокой. По мне так просто перенесли проблему в другую область - правила. С типами ничего не решено - всё равно явно проверять типы в правилах? Как не запутаться в этих правилах? Волшебник не может иметь меч, кроме одетых в белую мантию или на поляне единорогов? Считаю тема не раскрыта, ушёл думать.
Так и есть. Разработчик компилятора c# в итоге пришел к выводу, что моделировать предметную область с помощью типов c# - плохая идея и вряд ли получится что-то хорошее. Он предлагает моделировать задачу, отражая в виде классов в первую очередь то, как пользователь (клиент) программы взаимодействует с данными.
Комментаторы в предыдущих выпусках, которые имели опыт гймдева, настойчиво предлагали ввести список разрешённого оружия для игрока. Это и есть правила, о которых пишет Липперт.
Просто примеры как не надо сделаны хоть как-то на шарпе, а как надо - только текст. И типы Шарпа плохие, это я понял. Вывод: Шарп не годится вообще или что имел ввиду автор? Какое то словесное обещание коммунизма без конкретики.
Скорее ООП, как оно сделано в C-подобных языках, не годится для моделирования предметной области. Нужен другой язык. Возможно DSL.
Но это не главное. Главный вывод всей серии в том, что концентрироваться надо на задаче , а не на модели предметной области.
Получается, DDD который практикуют в .net c# -- это тоже все, в принципе, не подходит? И нужен DSL? Или это к игровой индустрии относится?
Вот представьте. что у нас есть пошаговая онлайн-рпг в браузере с простой графикой. Каждый ход сохраняется в базу данных.
Игроки управляют персонажами типа Маг, Воин итд, у которых есть оружие. Ровно как описано в этой серии постов.
Как DDD поможет решить проблемы, описанные в этой серии? В чем принципиально такая игра отличается от корпоративного приложения? Как бы вы спроектировали такую игру?
Почему одно автоматически исключает другое? Концентрация на DDD приводит к попытке выразить предметную область средствами языка, ООП. Но эти средства и ООП не являются подходящим инструментом для этого. А так как пользователя совершенно не волнует и не интересует никакое DDD, ему нужно решать конкретные задачи, а задачи выражаются данными, действиями над данными и событиями (эффектами, реакциями). По сути, практически любая программа -- это управление состоянием. Так может и сконцентрировать свои усилия именно на том, что требуется? Это вовсе не значит, что DDD не подходит, только выражается оно не через ООП, а через архитектуру состояния, DSL, правилами. Все в выигрыше.
Воины и волшебники, часть пятая, финал