Реализация микросервисной архитектуры CRM HRM и проблем проектирования предметной области

Мы создаем корпоративную платформу, состоящую из CRM, HRM, ПРОДАЖИ, СОБСТВЕННОСТИ и т. Д. Мы работаем над микросервисной архитектурой.

Реальный вопрос: CRM и HRM будут развернуты как отдельные независимые микросервисы, но часто эти два микросервиса должны взаимодействовать друг с другом. Пользователь HRM создает контактного сотрудника компании, и API микросервиса HRM сохраняет информацию, относящуюся к HRM внутри модуля HRM, в базе данных «hrm», в то время как данные сотрудника, такие как имя, фамилия, адрес и т. Д., Будут сохранены в базе данных CRM, вызывая API микросервисов CRM, т.е. API контактов сохраняет указанную выше информацию как контакт типа «Внутренний» или «Сотрудник». Итак, в основном я пытаюсь разделить данные, относящиеся к каждому микросервису.

Правильно ли этот способ проектирования домена? или мне нужно обрабатывать и хранить всю информацию (введенную авторизованным пользователем HRM) в модуле HRM и базе данных hrm? так что нам наплевать на CRM. И если так, кажется, что CRM управляет только ВНЕШНИМИ контактами? Будут ли у этого проблемы в будущем?


microservices architecture crm domain-driven-design erp
person PainPoints    schedule 23.11.2015    source источник
comment
Не могли бы вы объяснить, как ваш вопрос относится к предметно-ориентированному дизайну (DDD)?   -  person guillaume31    schedule 24.11.2015
comment
В этом контексте CRM и HRM не являются огромными приложениями, которые мы видим каждый день. У меня есть несколько сервисов для работы со счетами, контактами и лидами в CRM. Точно так же несколько услуг, связанных с функциональностью HRM, и одна, например, добавление сотрудников. Итак, проблема DDD для меня заключается в том, что при добавлении сотрудника пользователем HRM: следует ли мне хранить информацию, связанную с HRM, в HRM, а также имя, адрес сотрудника и т. Д. В контактах CRM? ИЛИ HRM должен заниматься всем, что касается добавления сотрудника.   -  person PainPoints    schedule 26.11.2015
comment
Но я не вижу здесь никаких терминов, связанных с подходом к проектированию на основе домена (домены, поддомены, ограниченные контексты, агрегаты и т. Д.). Я просто спрашиваю, потому что боюсь, что вы неправильно использовали тег ddd в своем вопросе, и люди могут ответ не по делу.   -  person guillaume31    schedule 26.11.2015
comment
Итак, с точки зрения DDD, насколько я понимаю, вот полный контактный домен в CRM, то есть «Контакт» с идентификатором, именем, фамилией и адресом. Ограниченный контекст - это добавление / изменение / удаление контакта. Агрегат - это ContactService, отвечающий за добавление, изменение и удаление контактов. Точно так же Сотрудник, имеющий имя, фамилию, адрес и т. Д. В HRM, является полным доменом сотрудника. Ограниченный контекст находится внутри операций добавления / изменения / удаления сотрудника. Агрегат - это служба EmployeeService, отвечающая за добавление, изменение и удаление сотрудников.   -  person PainPoints    schedule 01.12.2015
comment
У меня вопрос: нужно ли рассматривать сотрудника как контактное лицо? Связаны ли эти 2 вещи на практике? если да, то есть ли у нас общий ограниченный контекст? таким образом, что ContactService является подмножеством операций EmployeeService. Есть ли практическая выгода для бизнеса от разделения таблицы контактов и таблицы сотрудников? Какова рекомендуемая практика, при которой любые новые функции будут корректироваться в соответствии с первоначальным дизайном?   -  person PainPoints    schedule 01.12.2015
comment
Дело не в том, что разделение таблицы контактов и таблицы сотрудников приносит пользу для бизнеса, а в том, что зачем вам вообще их собирать?   -  person guillaume31    schedule 01.12.2015
comment
Поскольку в требовании в модуле CRM уже есть модель контакта с именем, фамилией, адресом и т. Д. Модель сотрудника (в модуле HRM) имеет все поля модели контакта с добавленными двумя или тремя новыми свойствами, такими как jobStartDate, position . Мне пришли в голову такие вещи, как даже зачем дублировать модель, которая вместо этого приводит к избыточным кодам, повторное использование кодов, повторное использование пространства имен таблиц и т. Д., И я пытаюсь сделать вещи как можно более чистыми. Я чувствую, что отстаю в какой-то важной вещи, пожалуйста, подскажите, где я ломаюсь, пытаясь построить всю эту концепцию.   -  person PainPoints    schedule 02.12.2015
comment
Спасибо, guillaume31. Я получил ответы для решения моей реальной проблемы из вашего последнего ответа внизу страницы.   -  person PainPoints    schedule 02.12.2015

Ответы (2)


arrow_upward
0
arrow_downward

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

Контакт есть Контакт. Сотрудник - это Сотрудник. Не зря они носят разные имена. Они отражают разные концепции предметной области.

Если контакт не может каким-то образом оказаться также и сотрудником (что может сказать только эксперт в вашей области, и уж точно не кто-то в StackOverflow), у них нет причин делиться чем-либо - будь то таблица базы данных, базовый класс и т. д., и тем более, если они находятся в разных ограниченных контекстах.

person guillaume31    schedule 01.12.2015
comment
Большое спасибо, я получил больше света для решения моей проблемы из последнего упомянутого вами абзаца. - person PainPoints; 02.12.2015

arrow_upward
2
arrow_downward

Вот пара вещей:

1) CRM и HRM - не микросервисы. В этих доменах нет ничего микро.

2) В общем, вам нужно, чтобы между сервисами было как можно меньше связи. Это не означает, что вы не можете использовать композиционные шаблоны, но вы должны подумать, почему вы используете их в той или иной ситуации. Если вы делаете это только для того, чтобы избежать дублирования кода или базы данных, вам действительно следует относиться к этому скептически.

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

Я бы действительно посоветовал вам подумать о том, чтобы спроектировать их как отдельные магазины. Это позволит этим системам развиваться независимо, независимо масштабироваться и т. Д.

Если вы действительно хотите, чтобы все контакты были в одной системе, рассмотрите новую услугу (возможно, что-то более «микро»), которая хранит и извлекает контакты. Это может использоваться обеими службами, но не зависит от каждой из них.

person Rob Conklin    schedule 23.11.2015
comment
Голосование за CRM и HRM - это не микросервисы, они не являются ни микро, ни ограниченным контекстом. - person Yugang Zhou; 24.11.2015
comment
Спасибо за предложение. Контекст, который я описал для CRM и HRM, был вымышленным, просто чтобы проиллюстрировать суть дела. Я должен был спросить, например, «как взаимодействовать между несколькими микросервисами с обеспечением согласованности данных». - person PainPoints; 24.11.2015