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

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

    Наверное, самый "не костыльный" путь это NoSQL.
    Ответ написан
  • 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 предоставляет варианты использования бизнес логики в контексте данного приложения? „

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