МФ
для 1-2-3 юзкейсов со сменой статусов — да, круды в наиличе есть
но они заперты в своих контекстах, ПРОСТЫХ контекстах с простыми бизнес-процессами
но они заперты в своих контекстах, ПРОСТЫХ контекстах с простыми бизнес-процессами
Size: a a a
2021 October 26
МФ
не имеет значения, тк ДДД прост и достаточен для этой задачи
МФ
почему вы привязали ДДД к чему-то сложному? что там сложного?
есть процесс, который формализован и имеет границы (контекст), есть код, его описывающий, есть данные, которые очерчены этим контекстом
нашли рокет-сайнс
есть процесс, который формализован и имеет границы (контекст), есть код, его описывающий, есть данные, которые очерчены этим контекстом
нашли рокет-сайнс
МФ
а вот процедурщина в виде традиционных архитектур, коих большиснвто у нас — они чреваты почти на ровном месте запутать программистов и всех
МФ
> а если не формализирован?
он есть, этого достаточно
он есть, этого достаточно
МФ
да, предполагается, что нужно договриться с бизнесом, как это будет называться и где границы пролягут
МФ
выше добавил ответ: договариваться и формализовать
МФ
все равно это делать, иначе в архитектуре без ДДД что писать собрались?
МФ
это не имеет значения
тк это нужно делать в любой из архитектур, просто в одной это выражать паутиной, в другом выражать так, чем это является
в моей "низкой для вас" сложности ровно также надо вычленять фомральные признаки процесса
потому я и заявляю, что у меня есть ДДД, тк есть формальные признаки бизнес-процесса
тк это нужно делать в любой из архитектур, просто в одной это выражать паутиной, в другом выражать так, чем это является
в моей "низкой для вас" сложности ровно также надо вычленять фомральные признаки процесса
потому я и заявляю, что у меня есть ДДД, тк есть формальные признаки бизнес-процесса
МФ
можно и без формализации, с акцентом на данные и if/else когда что менять, но в случае 15 процессов (пусть и не формализованных) — это обилие таких изменений и пересечений над одной структурой
кроме того если структуры не ограничены бизнес-прцоессами, а некоторыми случайными правилами хаоса — это ад в проекте
кроме того если структуры не ограничены бизнес-прцоессами, а некоторыми случайными правилами хаоса — это ад в проекте
МФ
а значит ДДД — довольно универсальная пилюля починить работу в проекте и сделать жизнь лучше и прозрачнее, а не только дял ой какого сложного чего-то
МФ
можно конечно, но без ДДД, значит без ориентации на предметную область (согласно расшифровки аббревиатуры), а значит неявные правила изменения данных, непредсказуемые изменения и полное не понимание, что в системе происходит в случае увелиичения причин менять данные, кроме того данные могут быть из разных (будь они у нас) контекстов бизнеса
МФ
иными словами для обоснования необходимости ДДД нужна достаточная сложность, которая облегчит контроль и над процессами и над данными и будет олицетворять что же происходит в бизнесе
что я выше и обозначил
https://t.me/symfony_php/292404
что я выше и обозначил
https://t.me/symfony_php/292404
VK
Такое чувство что без ддд жизни нет