4-уровневая прикладная архитектура - серверный API с noSQL

Question

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

Я использую 4 слоя:

• Уровень данных

  • Принимает объекты с ключами
  • Предоставляет объекты из ключа
  • Предоставляет списки объектов из запросов
  • Предоставляет списки объектов из списков ключей
  • Принимает списки объектов с ключами
  • Удаляетобъекты из ключа
  • Реализует процедуры денормализации, основанные на определениях в модели (часто части одних объектов копируются в другие для ускорения запросов, поскольку соединения невозможны в noSQL)

• Бизнес-уровень

  • Обеспечивает бизнес-логику
  • Обеспечивает права доступа

• Model Layer

  • Определяет известные объекты
  • Определяет денормализацию (какие части объектов копируются в другие части)
  • Определяет разрешения (какие пользователи могут получить к ним доступобъекты при каких обстоятельствах)

• Уровень представления (RESTful API)

  • Предоставляет API покоя для всех ресурсов / служб, включая
    • Доступ к объектам и их изменение
    • Подготовка новой учетной записи пользователя
    • Вход в учетную запись
    • Все остальное, что необходимо API для "выполнения"

У меня есть несколько вопросов о том, как мне это настроить:

1) Я считаю, что информация, определяющая денормализацию (как и когда копиинекоторые объекты становятся доступными в других объектах) является частью определения модели, поэтому у меня есть процедуры, которые предоставляют эту информацию в модели.Тем не менее, слой, который фактически должен это делать, это Datalayer, в частности, когда информация сохраняется, поэтому я поставил процедуры для реализации определений денормализации, найденных в модели, на уровне данных.Это правильно?

2) Точно так же у меня есть определения разрешений (кто может получить доступ к какой информации и при каких обстоятельствах) в модели.Но бизнес-уровень будет нести ответственность за доставку этой информации в REST API, так что это уровень, на котором у меня есть права доступа.У меня нет уровня данных, обеспечивающего разрешения, потому что, хотя некоторые пользователи могут не иметь прямого доступа к некоторым данным, эти данные могут быть изменены косвенно через другие действия, которые выполняет пользователь (например, простой вход в систему может обновить свойство "last_login_time" этого пользователяхотя пользователь никогда не сможет изменить эту информацию по своему усмотрению) Это правильно?

3) Есть ли здесь что-то еще, что я ошибаюсь, что-то в общем, что я должен остерегаться, или что-то еще, что я должензнаете?

4) Я использую Google App Engine для этого, либо Python Java API низкого уровня.Есть ли рамки, которые я должен использовать, которая уже обрабатывает некоторые из них, в частности, денормализацию и разрешения?

Спасибо!

Answer 1

Не зная, насколько сложны ваши данные, почему слой данных отделен от модели? Я склонен добавлять функциональность в мои модели Google App Engine, чтобы делать все, что им нужно, чтобы принимать данные и получать данные на бизнес-уровне.

Кроме того, почему вы планируете использовать API низкого уровня вместо помощников, которые делают настойчивость такой же легкой, как падение?

Я думаю, вам следует сделать пару шагов назад, определить проблему, которую вы пытаетесь решить, и посмотреть, что встроил Google App Engine для ее решения. Мне нужна информация о том, чего вы пытаетесь достичь, прежде чем рассказать, как это сделать.