• Как называется такая архитектура и как лучшего всего ее реализовать?

    UnknownHero
    @UnknownHero
    1. NoSql
    2. postgresql json . Там даже поиск можно внутри json делать.
    3. Создавать таблицы-декораторы и связывать их Many - To - Many . В таблице связи иметь поля type. Внешние ключи при этом работать не будут.

    Наверное, самый "не костыльный" путь это NoSQL.
    Ответ написан
  • Как держать в голове проект по программированию над которым работаешь не каждый день?

    UnknownHero
    @UnknownHero
    Если пишите тесты, то перед окончанием работы создавайте нерабочий тест.
    Когда сядите заново, запускаете тесты и вспоминаете , что хотели сделать в последнйи раз.
    Ответ написан
    Комментировать
  • Какими back-end фреймворками Node.js пользуются большие компании?

    UnknownHero
    @UnknownHero
    Вот cписок ползователей Express
    Sails тоже работает на express.

    Я думаю что большие игроки будут составлять свою архитектуру из маленьких компонентов, спасибо npm
    Ответ написан
    Комментировать
  • Как понять суть программирования (подробнее в содержании)?

    UnknownHero
    @UnknownHero
    Человек не тратит сотни часов и дней на изучение композиции, как строится перспектива, как падает свет, как формируются тени, чтобы понять, подходит ли ему рисование или нет, хочет он заниматься этим или нет.

    Если мыслить так, то возьмите любую программу, например Skype.
    Начинайте представлять как команда разработчиков каждый день вносит изменения, придумывает функционал, делает ошибки или наоборот делает новые возможности для своих коллег.
    Представьте как миллионы пользователей экономят кучу денег и времени с помощью этой программы.
    Подумайте о доходах фирмы.
    А теперь представьте себя программистом в этой команде и думайте , что ещё неделю назад вы написали новый функционал для этой программы, а уже завтра миллионы людей будут ей пользоваться.

    Понравилась роль программиста ?

    С моей точки зрения это всё работает не так. Любому может понравиться картина художника и он захочет стать художником.
    Но уже через 100 часов обучения он бросил это дело, т.к. сам процесс ему не понравился.
    Поэтому лучше понять это в процессе.

    Программирование сейчас охватывает очень много сфер, люди придумывают магазины, сервисы, роботов, гаджеты и всем нужны программисты.
    Программист - это тот, кто может сделать идею в работающую программу и решить свою или чужу проблему.
    Чем опытнее программист, тем более сложны задачи он сможет решать.

    Если вам нравиться эта идея, то можете выбирать этот путь.
    Если сомневаетесь,я думаю, поможет только практика.

    А что на счёт разных языков или технологий... В любой сфере нужно будет иметь немалые начальные знания и постоянно учиться.
    Просто нужно взять что-то одно и выучить.
    Ответ написан
    Комментировать
  • DDD. Layers, Persistence Ignorance. Что куда?

    UnknownHero
    @UnknownHero Автор вопроса
    Ибо ответ так и не найден, продолжу монолог.
    Ещё одним хорошим решением было хранить интерфейсы для репозиториев.
    В этих интерфейсах должны быть такие методы как GetLastUser, GetRockMusic()… На основе паттернов Repository и Specification б такие методы будут содержать 1-2 строчки реализации, что очень и очень удобно. И полезно при оптимизации запросов.

    Спустя какое-то время как я задал вопрос, мне выпола возможность почитать больше книг и статей.
    Сейчас же когда я читаю свои же вопросы, начинаю понимать их размытость, иногда некорректность.

    Так что, если вы дорогой читать задаётесь теме же вопросами, просто копайте более глобально, обязательно найдёте другую дорожку.
    А лучше найдите DDD-практика и учитесь у него :)
    Ответ написан
    Комментировать
  • DDD. Layers, Persistence Ignorance. Что куда?

    UnknownHero
    @UnknownHero Автор вопроса
    Перебирая всевозможные комбинации слов в гугле нашёл первичные ответы на свои же вопросы:

    1. Все манипуляции с БД делаем с помощью Repository/UnitOfWork в слое Application.
    2. Нет. Ибо Persistence Ignorance
    3. Да.
    4. Тут можно выделить 2 вида спецификаций — Бизнес и БД. Спецификации бизнес логики храним в Domain слое. Так же есть спецификации для определённых ORM / БД, но сейчас не могу найти конкретный пример.
    5. Бизнес логика должна быть спроектирована так, что бы не возникало подобных ситуаций. Но если всё таки нужно, то можно реализовать
    Domain Events. Создаём внутри домена, подписываемся на них в слое Application, и «поджигаем» во время выполнения какого-то бизнес процесса.
    И Domain ничего не знает про логгеры/бд/etc и задача выполняется.
    Из минусов можно считать непредвиденные для бизнес логики ошибки во время выполнения обработчиков события. Но и тут я думаю можно избавится от проблемы на уровне Application слоя.

    И всё же остаются вопросы как выбирать данные из БД во время выполнения бизнес процесса. Здесь всё становится проще, если понимать и использовать Aggregation Root.

    Звучит всё достаточно хорошо, но теперь вытекает следующий вопрос что такое Application layer, что он делает, а что не делает?
    Правильно ли выражение «Application layer предоставляет варианты использования бизнес логики в контексте данного приложения? „

    Естественно все выводы не подкреплены большим опытом, так как всё было получено в спешных эксперементах.
    Поэтому жду критику, обсуждения и размышления.
    Ответ написан