Привет!
Пошёл полистать Lean Architecture в поисках инфы как писать юзкейсы и вообще форматов описания требований.
И потихоньку переполз на DCI.
И в это прочтение у меня три новых мысли возникло.
Мысль первая
Тезис, что ООП - это то как мир представляют нормальные люди - фикция.
ООП, по определению объекта (состояние + поведение), предполагает активность объектов.
Например счёт может (сам) сделать перевод. Или напечатать себя.
Но обычные пользователи (в лице моей жены) не мыслят категориями, что счёт сам переводит деньги или сам себя печатает. Они (она) мыслит скорее категориями 19-ого века, где есть карточка с информацией о счёте, и служащий банка, который выполняет её поручения по переводу денег или печати счёта.
Наверное поэтому, "полнокровная" доменная модель не вытеснила анемичную доменную модель в мейнстриме. Тупые сущности и умные сервисы - это то, как наши пользователи думают о наших информационных системах.
Мысль вторая
Возможно, за всей этой движухой лежит желание получить полиморфное поведение - удобно же иметь PrintableAccount, который можно использовать в обработчике "Напечатать выписку" и не парится когда, появляется новый тип счёта.
Но это не удобно, когда появляется новая операция над счётом (закрыть, например) - тогда придётся писать код закрытия счёта в пачке классов, а не одной функции.
Это типовой пример Expression problem (aka Data/Object Anti-Symmetry из 6ой главы чистого кода).
И, наверное, ООП и правда стрельнуло только на волне GUI - там как раз чаще появлялись новые типы, чем новые методы.
Но на бэке информационной системы, намного чаще появляются новые операции, чем типы.
Поэтому "полнокровная" доменная модель ведёт не только к тому, что изменения приходится вносить в множество мест, но ещё и к огромным с десятками методов для совершенно разных контекстов объектов с низким cohesion и высоким coupling.
Мысль третья
DCI - это ещё одна попытка решить expression problem.
И если у вас её нет (а у меня нет - очень редко появляются иерархии типов сущностей) - то и DCI не надо.
#whynotoop@ergonomic_code #dci@ergonomic_code #lean_architecture@ergonomic_code
Пошёл полистать Lean Architecture в поисках инфы как писать юзкейсы и вообще форматов описания требований.
И потихоньку переполз на DCI.
И в это прочтение у меня три новых мысли возникло.
Мысль первая
Тезис, что ООП - это то как мир представляют нормальные люди - фикция.
ООП, по определению объекта (состояние + поведение), предполагает активность объектов.
Например счёт может (сам) сделать перевод. Или напечатать себя.
Но обычные пользователи (в лице моей жены) не мыслят категориями, что счёт сам переводит деньги или сам себя печатает. Они (она) мыслит скорее категориями 19-ого века, где есть карточка с информацией о счёте, и служащий банка, который выполняет её поручения по переводу денег или печати счёта.
Наверное поэтому, "полнокровная" доменная модель не вытеснила анемичную доменную модель в мейнстриме. Тупые сущности и умные сервисы - это то, как наши пользователи думают о наших информационных системах.
Мысль вторая
Возможно, за всей этой движухой лежит желание получить полиморфное поведение - удобно же иметь PrintableAccount, который можно использовать в обработчике "Напечатать выписку" и не парится когда, появляется новый тип счёта.
Но это не удобно, когда появляется новая операция над счётом (закрыть, например) - тогда придётся писать код закрытия счёта в пачке классов, а не одной функции.
Это типовой пример Expression problem (aka Data/Object Anti-Symmetry из 6ой главы чистого кода).
И, наверное, ООП и правда стрельнуло только на волне GUI - там как раз чаще появлялись новые типы, чем новые методы.
Но на бэке информационной системы, намного чаще появляются новые операции, чем типы.
Поэтому "полнокровная" доменная модель ведёт не только к тому, что изменения приходится вносить в множество мест, но ещё и к огромным с десятками методов для совершенно разных контекстов объектов с низким cohesion и высоким coupling.
Мысль третья
DCI - это ещё одна попытка решить expression problem.
И если у вас её нет (а у меня нет - очень редко появляются иерархии типов сущностей) - то и DCI не надо.
#whynotoop@ergonomic_code #dci@ergonomic_code #lean_architecture@ergonomic_code
Wikipedia
Expression problem
Data abstraction problem in programming languages
👍4