Задать вопрос
Ответы пользователя по тегу Проектирование программного обеспечения
  • Clean Architecture. Как спроектировать отображение в UI процесса выполнения длительной бизнес-операции?

    DollyPapper
    @DollyPapper
    Мартин придумал сову, а вы теперь на свой глобус ее натягиваете. Не знаю что за OutputPort, видимо в терминологии из статьи это View Model. Примерно так это может выглядеть схематично66eaf0cd5ca32926811795.png
    Ответ написан
    1 комментарий
  • Как не нарушать границы компонентов при подходе package-by-feature?

    DollyPapper
    @DollyPapper
    Ну вызывать на прямую я бы не стал, иначе зачем вы это все делали. Нам от других слоев и пакетов обычно нужны некие данные. Можно передавать DTO между пакетами. Т.е. за получение данных отвечает так же пакет, и другой пакет эти данные использует.
    Ответ написан
    Комментировать
  • Консистентность данных в микросервисах?

    DollyPapper
    @DollyPapper
    Оттого и вопрос - можно ли обойтись без всего этого, сохранив плюсы реализации транзакционных механизмов РСУБД на микросервисах?

    Паттерны распред. транзакций от того и появились, что нельзя. У вас физически несколько разных БД на разных хостах. Транзакция это свойство систем хранения данных, когда мы атомарно фиксируем некоторое состояние системы в БД. В распределенной системе - в нескольких БД. Сайд эффекты типа отправки СМС не имеют никакого отношения к транзакциям. Либо отправляйте СМС после полной фиксации транзакции, либо как вариант используйте компенсирующую СМС, типа - "Извините мы ошиблись на самом деле мы не сделали того о чем мы писали в прошлой смс", но это уже в порядке бреда.
    Ответ написан
  • Как организовать архитектуру кода для взаимодействия с БД в Golang?

    DollyPapper
    @DollyPapper
    Тут все зависит от того как вам удобно, кто бы что не говорил, нет единого стандарта нужно/не нужно. Я наоборот чаще вижу что вместо прямого источника данных подают репозитории в сервисы. И сам так делаю. Это банально удобней тестировать.
    Ответ написан
    Комментировать
  • Существуют ли в opensource-проекты с хорошей архитектурой?

    DollyPapper
    @DollyPapper
    Надо исходить из изначального посыла - что такое хорошая архитектура и надо различать понятия дизайн и архитектура. Архитектура это высокоуровневая концепция. Это вопрос какую БД выбрать, какой прокси сервер, определение нагрузки на приложение. Так же архитектура это то сколько и какие слои в вашем приложении будут. А вот SOLID это как раз про дизайн отдельных модулей и классов. Итак. Какие изначальные постулаты "хорошего дизайна"?
    1. Понятность/читаемость кода
    2. Слабая связанность и сильная связность (зацепление) отдельных модулей
    3. Разделение компонентов по ответственностям
    4. Возможность повторного использования компонентов
    5. Надежность (вопрос устойчивости и корректности ПО)


    Исходя из этих критериев и нужно рассматривать архитектуру приложения. Но вот так просто "с улицы" зайти в проект и понять хорошая там архитектура или плохая ИМХО нельзя. Если пресловутые принципы SOLID нарушаются в приложении, то может так и задумано? Мартин вот категорично говорит, что нельзя зависеть от конкретных реализаций. Если у вас в зависимостях есть конкретный класс, а не интерфейс, то это якобы плохой дизайн, вы нарушаете принцип SOLID. Так ли это важно и нужно? Да не особо. Если нет смысла зависеть от интерфейса, то не надо пихать его. В этом и заключается чуйка архитектора. Если он считает, что реализация меняться не будет, то не нужно усложнять код. Если он считает, что требования будут меняться и следственно реализация, то вероятно стоит защитить конкретный компонент и выделить интерфейс. Если класс на 30к строк это не значит, что там плохая архитектура. Кто-то скажет, что это вполне себе Domain Model паттерн, вместо Anemic Model и это хороший дизайн, кто-то скажет что нарушается SRP. Нет четких правил, тут именно что нужно понимать предметную область с которой работаешь и вырабатывать чуйку.
    Ответ написан
    Комментировать
  • Как еще можно реализовать "внутреннее API" в веб-приложении, кроме как через ООП или HTTP?

    DollyPapper
    @DollyPapper
    Если цель собственно в декаплинге, то больше и никак. Либо DI либо какой-то "API", где под API имеется ввиду запрос к чему-то внешнему относительно нашего приложения, либо реальный API, либо какие нибудь, сокеты, очереди, etc. Во втором случае каплинга как такового не будет вовсе.
    и инверсию контроля
    - инверсия контроля (IoC) это немного про другое, вы имели ввиду Dependency Inversion скорее всего.
    Ответ написан
    Комментировать
  • Какой практический туториал по ddd посоветуете?

    DollyPapper
    @DollyPapper
    Через N лет вы перечитаете свой вопрос и поймете на сколько он бессмысленный. Нет таких статей, нет даже десятка статей. Вернее они есть, и можно из сотни статей собрать книгу, но потом эту книгу придется читать, перечитывать, осмысливать и переосмысливать десятки и сотни раз. Я даже не знаю если честно, что вам ответить, по скольку любой ответ на столь наивный вопрос не даст вам понимания (если, что я не хочу вас принизить как-то, просто это на столько мудреная тема, что тут правда нужно на определенный уровень мозг настроить в этой теме, чтобы начать понимать хоть что-то). Могу лишь сказать, что не пытайтесь с наскоку по какой-то статье понять архитектуру ПО. Почитайте Роберта Мартина поймите в чем заключается смысл проектирования вообще. Потом идите писать свои приложения основываясь на вновь полученных знаниях и пытайтесь понять где у вас что не так с архитектурой и как это улучшить. И на вопрос "как улучшить" уже ищите ответы в книгах. В DDD пока вообще не лезьте, это тема концептуально даже выше архитектуры.
    Ответ написан
    Комментировать
  • Как правильно разделять код между Контроллером и Сервисом?

    DollyPapper
    @DollyPapper
    Сервисы уровня домена это то место, где хранится бизнес логика вашего приложения (при анемичной модели, то есть той, которая не имеет в себе бизнес логики), сервисы уровня приложения, это вспомогательная логика для приложения, но не связанная с доменом. Контроллеры же - транспорт. Их задача запрос принять, обработать, вызвать кого нужно, сервисы из уровня домена, сервисы уровня приложения и т.д. и отдать ответ обратно. Логики в них должно быть по минимуму. По логике описанной вами ArticleService не должен ничего сам сохранять, это задача ИМХО StorageService, и ArticleService должен эту работу ему делегировать.
    Ответ написан
    Комментировать
  • Где найти книги или курсы по PHP, где даётся проектирование приложений с учётом ООП?

    DollyPapper
    @DollyPapper
    Их не нужно сравнивать. Эти подходы дополняют друг друга. Внутри методов класса ты как ни крути пишешь процедурный код.
    Ответ написан
    Комментировать
  • Болезнь творца или как создать свой виртуальный мир?

    DollyPapper
    @DollyPapper
    Господи насоветовали ему всякого, архитектуру продумай, то продумай, сё продумай. Человек вон жалуется мол, нахуа мне эта ваша математика нужна, неужели нельзя попроще. репортим и расходимся, это некропост.
    Ну а если все же натравите крон на свою игру, то в ближайшем апдейте завезите огробления корованов.
    Ответ написан
    Комментировать