Здравствуйте, Alekzander, Вы писали:

A>Откуда же берётся такое г-но, описанное Липпертом?

A>Да вот оттуда и берётся. Когда, допустим, я говорю: в хорошем коде отражается предметная область. А, допустим, ты говоришь: это бла-бла-бла, гони конкретику. Допустим, я не понимаю, что не каждый фундаментальный принцип — такой, как доменной дизайн или второе начало термодинамики — можно свести к набору более простых правил (это свойство называется "эмерджентность"), и чтобы хоть что-то тебе ответить, говорю: выпиши в блокнот игровые понятия и проследи, чтобы каждому соответствовал хоть какой-то сишарповский класс. И вот результат.

A>К счастью, это был просто пример. А реальный я скажу тебе, что нет таких приёмов, которые можно применять не думая, чтобы обеспечить выполнение этого принципа (почему — я уже объяснил: это запрет, налагаемый законами природы на творческие процессы). А если делать это думая, то указанный принцип должен быть воплощён в форме класса, который считывает приготовленные карточки. Потому, что именно так НА САМОМ ДЕЛЕ устроена предметная область. И несмотря на высокоуровневость этого принципа, смысл в нём есть. Например, если ты напишешь код считывания констрейнтов на оружие в отдельном хелпере — ты его нарушишь.

То есть у нас появился объект "считыватель карточек Х", где Х — термин предметной области, так? Это ведь уже не совсем ubiquitous language, про который говорит DDD.

Продолжаем мысленный эксперимент с софтом для МРТ. Предположим у нас не просто аппарат, а целая система, когда аппарат снимки на сервер сохраняет, а компьютер у врача, возможно совершенно в другому месте, отображает. Так вот по этой логике какой класс должен заниматься сохранением карточек\файлов МРТ на сервере и их считыванием на клиенте?