Здравствуйте, developer999999, Вы писали:
D>какие самые общие рекомендации по построению архитектуры вы можете дать? D>вне зависимости от платформ, технологий и предметных областей
не стреляй в голову
не ешь каку
задавай правильные вопросы
Еще более общие или достаточно?
Re: какие самые общие рекомендации по построению архитектуры вы можете дать?
Здравствуйте, developer999999, Вы писали:
D>какие самые общие рекомендации по построению архитектуры вы можете дать? D>вне зависимости от платформ, технологий и предметных областей
Здравствуйте, developer999999, Вы писали:
D>какие самые общие рекомендации по построению архитектуры вы можете дать? D>вне зависимости от платформ, технологий и предметных областей
Здравствуйте, developer999999, Вы писали:
D>какие самые общие рекомендации по построению архитектуры вы можете дать? D>вне зависимости от платформ, технологий и предметных областей
Имхо, все рекомендации идут как два противоположных утверждения, и выбор конкретной стороны или точки между ними зависит от конкретных обстоятельств.
Re: какие самые общие рекомендации по построению архитектуры вы можете дать?
Здравствуйте, developer999999, Вы писали:
D>какие самые общие рекомендации по построению архитектуры вы можете дать? D>вне зависимости от платформ, технологий и предметных областей
D>какие самые общие рекомендации по построению архитектуры вы можете дать? D>вне зависимости от платформ, технологий и предметных областей
Мухи отдельно, котлеты отдельно.
Модель — отдельно, вид — отдельно. Ну, и контроллер — тоже отдельно.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, developer999999, Вы писали:
D>какие самые общие рекомендации по построению архитектуры вы можете дать? D>вне зависимости от платформ, технологий и предметных областей
Это очень просто, в одной картинке:
Слева — та часть системы, с которой взаимодействует пользователь (веб, телефон, терминал, десктоп, служба), пользовательский интерфейс (UI). Справа — ядро системы, "бизнес-логика". UI общается с ядром через сообщения (RequestModel, ResponseModel), этим и обеспечивается их независимость друг от друга — можно нарисовать UI без ядра и написать ядро без UI. Общение UI и ядра координирует Interactor, умеющий получать запросы от UI и отправлять ответы от ядра — механизмом доставки сообщений заведует Boundary. Так же Interactor умеет пробуждать ядро к жизни с помощью Entity Gateway.
Запросы и ответы всегда двигаются в одну сторону:
Запрос: UI->(Request)->Boundary->Interactor->Entities
Ответ: UI<-Boundary<-(Response)<-Interactor<-Entities
Здравствуйте, developer999999, Вы писали:
D>какие самые общие рекомендации по построению архитектуры вы можете дать? D>вне зависимости от платформ, технологий и предметных областей
1) Single Responsibility Principle везде.
2) Single Responsibility Principle везде.
3) Single Responsibility Principle везде.
4) Стараться НЕ ДЕЛАТЬ абстрактных обобщённых решений. Даже на интерфейсы смотреть аккуратно — почему нужен именно интерфейс, а не класс? Если же возникает необходимость в особых фабриках или стратегиях — внимательно посмотреть на код, не решается ли вся проблема двумя if'ами вместо 5 классов.
Sapienti sat!
Re: какие самые общие рекомендации по построению архитектуры вы можете дать?
Здравствуйте, developer999999, Вы писали: D>какие самые общие рекомендации по построению архитектуры вы можете дать? D>вне зависимости от платформ, технологий и предметных областей
самое главное в архитектуре проекта — это люди, которые ее проектируют
я, например, заметил, что девелоперы, имеющие длинные странные ники из нескольких слов или странных цифр, не могут заниматься проектированием и их нельзя допускать до этого
Re[2]: какие самые общие рекомендации по построению архитектуры вы можете дать?
Здравствуйте, __kot2, Вы писали:
__>самое главное в архитектуре проекта — это люди, которые ее проектируют __>я, например, заметил, что девелоперы, имеющие длинные странные ники из нескольких слов или странных цифр, не могут заниматься проектированием и их нельзя допускать до этого
Здравствуйте, Vladek, Вы писали:
V>Это очень просто, в одной картинке: V>Image: arch.png V>Слева — та часть системы, с которой взаимодействует пользователь (веб, телефон, терминал, десктоп, служба), пользовательский интерфейс (UI). Справа — ядро системы, "бизнес-логика". UI общается с ядром через сообщения (RequestModel, ResponseModel), этим и обеспечивается их независимость друг от друга — можно нарисовать UI без ядра и написать ядро без UI.
Ага, а потом ещё туда добавить абстрактную фабрику архитектур, параметризованную стратегией создания visitor'а для полного полиморфизмуса головного моска.
Посылать надо таких проектантов сразу на три буквы. Лучше ещё и пинка под зад дать, чтобы не задерживались.
Нафиг никому не нужно рисовать UI без ядра, и наоборот. Потому backend должен делаться с учётом frontend'ов (которых можно планировать несколько штук). Ну и на backend'е на йух могут быть не нужны эти Interactor'ы, gateway'и, boundary и прочие request model. Вполне может иметь смысл его сделать в виде тонкой прослойки для формирования запросов к БД или другим сервисам.
Sapienti sat!
Re[3]: какие самые общие рекомендации по построению архитектуры
Здравствуйте, Cyberax, Вы писали:
C>Нафиг никому не нужно рисовать UI без ядра, и наоборот. Потому backend должен делаться с учётом frontend'ов (которых можно планировать несколько штук). Ну и на backend'е на йух могут быть не нужны эти Interactor'ы, gateway'и, boundary и прочие request model. Вполне может иметь смысл его сделать в виде тонкой прослойки для формирования запросов к БД или другим сервисам.
Ща докурю и пойдём сдавать.
Interactor'ы, gateway'и, boundary — это посредники в общении частей системы между собой. Нужны они или нет — можно выяснить для себя по этой картинке:
Она из самого начала книги "Мифический человеко-месяц", где выясняются различия между программой и программным продуктом.
Re[4]: какие самые общие рекомендации по построению архитектуры
Здравствуйте, Vladek, Вы писали:
V>Interactor'ы, gateway'и, boundary — это посредники в общении частей системы между собой.
Я это прекрасно знаю. И ещё раз повторяю — не нужны, кроме как в подавляющем меньшинстве случаев.
V>Нужны они или нет — можно выяснить для себя по этой картинке:
Не нужны.
V>Image: slide_48.jpg V>Она из самого начала книги "Мифический человеко-месяц", где выясняются различия между программой и программным продуктом.
А это вообще бред. Принципы проектирования абсолютно одинаковы для всего софта. Хоть для КОКОРЕШа, который ещё круче простого ламерского "программного продукта".
Моя команда недавно закончила рефакторинг такой рвотной массы предыдущего орхитектора на проекте (сейчас он в Facebook, кстати). Минус 40 тысяч строк без потери функциональности просто за счёт выбрасывания обобщённых частей и замены их простыми специфичными обработчиками. После чего мы легко добавили туда ещё немного специфичных случаев для новой функциональности.
Я называю такой процесс "debridement" ("санация") — жаль, что про него в учебниках не пишут.
Sapienti sat!
Re[5]: какие самые общие рекомендации по построению архитектуры
Здравствуйте, Cyberax, Вы писали: C>Моя команда недавно закончила рефакторинг такой рвотной массы предыдущего орхитектора на проекте (сейчас он в Facebook, кстати). Минус 40 тысяч строк без потери функциональности просто за счёт выбрасывания обобщённых частей и замены их простыми специфичными обработчиками. После чего мы легко добавили туда ещё немного специфичных случаев для новой функциональности. C>Я называю такой процесс "debridement" ("санация") — жаль, что про него в учебниках не пишут.
да, кстати, это типичная ошибка начинающих — они думают, что чем больше кода в проекте, тем лучше. ведь кто-то его писал, старался его можно там переиспользовать наоборот, чем меньше, тем лучше, любой говнопроект можно взять и просто выкидывать оттуда чуть ли не модулями какахеры от аффтаров без потери функциональности
Re[5]: какие самые общие рекомендации по построению архитектуры
