Ограниченный контекст

Обсуждаем, как правильно строить приложения
Ответить
Trent
Сообщения: 10
Зарегистрирован: 2019.04.25, 08:43

Ограниченный контекст

Сообщение Trent » 2019.06.23, 07:32

Здравствуйте. Помогите новичку

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

Скажите, это ведь три разных "поддомена", так?

1) Делаем Company с набором своих агрегатов (ну точней, наверное, там один агрегат будет Company, включающий в себя всякие сущности Company, Product, Employee, репозиторий на создание, редактирование, добавление услуг, ну и сервисы на это)
2) Делаем CompanyAccount (Для компаний, который хотят работать с бизнесом, там тоже будет сущность (агрегат) Company (без возможности создания, но с редактированием), Product, Employee, но добавятся агрегат Account и другие какие то либо действия, которые может будут в последствии)
3) Делаем User (ну там свой личный кабинет и прочее).

Вот в чем вопрос: Делать 1 - Company и 2 - CompanyAccount и, собственно, проще делать доступ для всех пользователей, но код дублируется в разных доменах или всё "запихать" в один Company и делать потом разделение на инфраструктурном уровне? Использовать они будут одни и те же таблицы в базе (или в API), что с точки зрения возможности потом поддерживать код будет лучше?

Пользователь сайта - User
Пользователь организации - CompanyAccount
Администратор сайта - Company

Извините, если вопрос не туда, а то названий нахватался, но нужно их структуизировать

anton_z
Сообщения: 435
Зарегистрирован: 2017.01.15, 15:01

Re: Ограниченный контекст

Сообщение anton_z » 2019.06.23, 13:20

Я думаю не стоит делить. Тут важна цель приложения - чтобы потребители нашли себе поставщиков. Соответственно и домен один. Тем более что база у вас одна и та же. Это признак того, что разделение не нужно. Если над проектом работает одна команда, а не несколько раздельных, то поддерживать будет проще один проект. Я бы не делил домены, а чисто технически, разделил бы серверную и клиентскую часть на отдельные приложения. Клиента сделал бы SPA на js, который бы ходил к серверу через JSON RPC или RESTful поверх HTTP. Но это если проект не будет содержать публичных страниц, которые надо индексировать поиском.

Trent
Сообщения: 10
Зарегистрирован: 2019.04.25, 08:43

Re: Ограниченный контекст

Сообщение Trent » 2019.06.23, 13:50

Спасибо за ответ. Я уже, правда, надеялся, что мне ответят "разделяй"), ибо, кажется, технически тогда легче разделять доступ (хоть сразу несколько приложений сделать можно). Но да, база одна будет у компаний. Видимо, вы правы.
P.S. Клиент придется делать обычный, индексация нужна. Всё-таки в серверный рендеринг SPA я до сих пор не верю)

Trent
Сообщения: 10
Зарегистрирован: 2019.04.25, 08:43

Re: Ограниченный контекст

Сообщение Trent » 2019.07.07, 15:05

А есть ли практика разделять сервисы по "уровню доступа"?

Например CompanyAdminService или CompanyUserService?

anton_z
Сообщения: 435
Зарегистрирован: 2017.01.15, 15:01

Re: Ограниченный контекст

Сообщение anton_z » 2019.07.08, 12:50

Я так делаю иногда, особых проблем с подобными классами не имел.

Trent
Сообщения: 10
Зарегистрирован: 2019.04.25, 08:43

Re: Ограниченный контекст

Сообщение Trent » 2019.07.08, 19:47

Ну отлично, спасибо. Тогда еще абстрактгый класс над ними поставлю

Ответить