Comments 25
Отличная статья! Думаю на заметку многим понадобиться, чтобы себе жизнь упростить
+1
В данной статье я хотел бы рассказать об этих трёх буквах
Что же вы так пугаете вначале статьи?
+3
Те 3 буквы тоже имеют некоторое отношение к DDD ;)
+2
Что характерно, три буквы захватывают мир
(DDD) Domain Driven Design
(TDD) Test-Driven Development
(MDA) Model Driven Architecture
(UML) Unified Modeling Language
(OOP) Object-oriented programming
(AOP) Aspect-oriented programming
(MVC, MVP) Model-View-Controller
(SOA) Service-oriented architecture
(IoC) Inversion of Control
(ORM) Object-relational mapping
Чуиит мое сердце без НЛО тут не как не обошлось!
(DDD) Domain Driven Design
(TDD) Test-Driven Development
(MDA) Model Driven Architecture
(UML) Unified Modeling Language
(OOP) Object-oriented programming
(AOP) Aspect-oriented programming
(MVC, MVP) Model-View-Controller
(SOA) Service-oriented architecture
(IoC) Inversion of Control
(ORM) Object-relational mapping
Чуиит мое сердце без НЛО тут не как не обошлось!
+3
Не хотел писать бессмысленный комментарий, но порыв слишком силен…
Мне кажется, к списку стоит добавить WWW
Мне кажется, к списку стоит добавить WWW
0
UML и MDA можно смело вычеркнуть как «пережитки прошлого».
-2
Я безнадежно отстал или еще не развился. Что вместо них? Где почитать?
0
Ничего. Они просто умерли. Причем UML «отошел» уже давно, а что касается MDA то он, собственно, никогда не был настолько популярным чтобы его кто-то массово использовал или даже встраивал в продукт. Хотя нет, постойте, вроде Borland делал какие-то подвижки в этом плане, но если учесть что их IDE вроде как «накрылась» (по крайней мере я даже ее названия не помню, а это показатель), то они тоже не в счет. При этом концепт MDA в принципе хороший, но разработчексий мир ее попросту обогнал, показав что нельзя обобщать концепции UML и представлять их для кодогенерации (причем в разных языках и фреймворках). Это просто не работает, не работает и хоть тут тресни. От того мы и имеем такие вещи как DSLы — потому что соль нашего производства — доменная специфика. И никакой UML должным образом не позволяет нам описать системы, которые используют метапрограммирование, AOP, DI, динамической программирование, да и банальные фичи языка вроде использования методов расширения. Нотации не хватает, а главное — неясно зачем вообще напрягаться если наше восприятие все равно должно идти через код, а не через идеологические абстракции, половина которых сыпется в пух и прах как только мы пишем наш первый юнит-тест.
Сугубо имхо, как всегда :)
Сугубо имхо, как всегда :)
-1
Большое спасибо! Из всех вышеперечисленных книг довелось пощупать только первую (Фаулер), теперь буду знать, что щупать дальше.
Чесно говоря, во время прочтения Фаулера я никак не мог сконцентрироваться на тонкостях — очень много описанных им паттернов очевидны или же попадались мне на практике, а читать то, о чем уже знаешь, довольно тяжело.
ИМХО подобные книги надо читать в два приема — сначала по диагонали, чтоб знать, какой паттерн за что отвечает, а потом, непосредственно при проектировании, внимательно для выяснения всех ньюансов.
Чесно говоря, во время прочтения Фаулера я никак не мог сконцентрироваться на тонкостях — очень много описанных им паттернов очевидны или же попадались мне на практике, а читать то, о чем уже знаешь, довольно тяжело.
ИМХО подобные книги надо читать в два приема — сначала по диагонали, чтоб знать, какой паттерн за что отвечает, а потом, непосредственно при проектировании, внимательно для выяснения всех ньюансов.
0
Хорошая статья, сейчас как раз читаю книгу Джимми Нильсона, остальные видел, слышал, но ручки еще не дотянулись. Единственное, что хотел отметить, так это то что данные книги лучше читать в оригинале. ИМХО русский перевод немного отдает «корявостью».
+1
Меня смутила следующая фраза у вас в топике: «первые два шаблона более привлекательны в начале работы с предметной областью». Т. е. вы предлагаете начать проект с Transaction script, а затем перейти к Domain Model?
Тут стоит понимать, что подход нужно выбрать с самого начала проекта. Если повнимательней почитаете Фаулера, то увидите, что он как раз это и объясняет.
Тут стоит понимать, что подход нужно выбрать с самого начала проекта. Если повнимательней почитаете Фаулера, то увидите, что он как раз это и объясняет.
0
О, теперь есть куда отправлять новичков начинать разбираться с DDD.
Сам особо советовал бы книжку Эрика Эванса, очень там доступно все напиано.
Сам особо советовал бы книжку Эрика Эванса, очень там доступно все напиано.
0
По-моему статья экстра-абстрактная и пиарская.
Лучше было бы пример конкретный разобрать и внизу дать все эти ссылки.
Лучше было бы пример конкретный разобрать и внизу дать все эти ссылки.
+2
UFO just landed and posted this here
Наверное не ubiquities a ubiquitous все же…
0
В статье устаревшая информация большая синея книга переведена Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем Эрик Эванс
0
Что скажете об этой книге: www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577/?
+1
Sign up to leave a comment.
Учимся проектировать на основе предметной области (DDD: Domain Driven Design)