DDD: логика, которая охватывает несколько моделей, куда она должна идти?

Я работаю в системе и пытаюсь использовать DDD с node.js. Вот пример для системы высокого уровня:

database tables(mongoldb):    
user    
username: String    
firstName: String    
middleName: String    
lastName: String    

department
title: String    
members: [{    
    user: {type: this.mongoose.Schema.ObjectId, ref: 'user’},    
    permissions: String    
}]    

patient   
user: {type: this.mongoose.Schema.ObjectId, ref: 'user’},    
department: [{type: this.mongoose.Schema.ObjectId, ref: ‘department’}]    

lab: [{    
    patient: {type: this.mongoose.Schema.ObjectId, ref: ‘patient’}    
    doctor: {type: this.mongoose.Schema.ObjectId, ref: 'user’},    
    type: String,    
    results: {there is a lot going on here, }    
}]

medication: [{    
    patient: {type: this.mongoose.Schema.ObjectId, ref: ‘patient’}    
    doctor: {type: this.mongoose.Schema.ObjectId, ref: 'user’},    
    name: String,    
    dosage: Number,    
    etc.    
}]

Бизнес-логика гласит, что только пациент или врач, являющийся членом одного из отделов в списке пациентов, могут просматривать свою медицинскую информацию. Сначала я думал, что он должен находиться в отдельной доменной службе, поскольку она, по-видимому, охватывает объекты, но недостатком является то, что другим службам потребуется вызывать службу разрешений, и я думал, что службы не должны вызывать другие службы. Если я помещаю в лабораторию и лекарства, то я дублирую код и нарушаю правила. Если я добавлю в службу домена отделы, то я заставлю службу позвонить в другую службу. С точки зрения DDD, где эта логика принадлежит?

1 ответ

Где вы взяли идею службы не должны вызывать другие службы. Безопасность обычно является отдельной услугой или чем-то еще.

Другие вопросы по тегам