Re[8]: Что если не разделять строго dto, entity, bo...
От: Kernan Ниоткуда https://rsdn.ru/forum/flame.politics/
Дата: 02.12.25 06:35
Оценка:
Здравствуйте, Qulac, Вы писали:

Q>Тут нет ни какого другого способа, кроме как работать с моделью. Если ее смог создать у себя бизнес, то собственно и мы можем ее сделать в программной реализации. Для этого ее нужно отделить от обслуживающих ее слоев, что бы нам ни чего не мешало сосредотачиваться на ней. Общий подход, если простыми словами: все есть модель, а остальное — "обслуга" модели. И важно: мы тут еще отделяем проблемную часть, от не проблемной.

Ну кулстори, конечно. Делай хорошо и будет всё замечательно. Я не согласен с этим. Вот по своей практике у меня сложилось мнение, что основные задачи проектирования это снижение сложности и создания архитектуры устойчивой к изменению требований, в разумных пределах конечно же. Если первое можно решать созданием удобных для использования типов данных, ну например, currency и money, то второе сводится к натягиванию предметной области на код в виде абстракций с сложным разграничением ответственности м/д классами и подход к разработке архитектуры через наши любимые принципы, паттерны, СОЛИД, GRASP и т.п. Однако, тезисы Ганджустата как-то говорят о том, на мой взгляд, что домены это хорошо, но пиши как знаешь и проще, всё равно по метрикам на большом проекте это не даёт особого профита. Вот как быть?
Sic luceat lux!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.