Наилучшая практика для сервис-ориентированной архитектуры и рекомендуемая максимальная длина линии

Question

Надеюсь, это не будет точкой личного мнения, но вместо этого урегулируйте аргумент коллеги, и у меня есть о дизайне приложения.

Мы используем шаблон хранилища для нашего уровня данных и сервисов для применения бизнес-логики. У службы может быть одно или, более вероятно, множество репозиториев внутри нее. Так давайте приведем пример (я не работаю в школе, но это просто пример):

Мои Хранилища могут включать в себя:

SchoolRepository 
ClassRepoistory 
DepartmentRepository 
TutorRepository 
TutorDepartmentRepository 
TutorSkillsRepository 
StudentRepository 
StudentClassRepository 

Так что в моем сознании, я бы три службы (мой примером может служить в C#, но это относится к любому языку):

public class SchoolService : ISchoolService 
{ 
    public SchoolService(ISchoolRepository schoolRepository, 
         IClassRepository classRepository, 
         IDepartmentRepository departmentRepository) 
    { 
     .... 
    } 
} 

public class TutorService : ITutorService 
{ 
    public TutorService(ITutorRepository tutorRepository, 
         ITutorDepartmentRepository tutorDepartmentRepository) 
    { 
     .... 
    } 
} 

public class StudentService : IStudentService 
{ 
    public StudentService(IStudentRepository studentRepository, 
          IStudentClassRepository studentClassRepository) 
    { 
     .... 
    } 
} 

Теперь, в моем примере TutorService потенциально нужны данные из DepartmentRepository и StudentService может также потенциально нужны данные из ClassRepository , Мой аргумент, должен вам нужен Class объект из ClassRepository оно должно быть извлечено из SchoolService и этот объект должен быть передан через в качестве параметра, как показано ниже:

// School service created by DI framework 
var class = schoolService.GetClassById(1); 

// Student service created by DI framework 
var student = studentService.GetStudentById(1); 
var studentClasses = studentService.GetStudentClasses(student, class); 

Я пометили еще один вопрос на мой титул этот пост также вокруг максимальных размеров классов. Я предположил, что это должно быть не более 500 строк (включая фигурные скобки {}, новые строки, чтобы сделать их доступными для чтения и т. Д.), Поскольку это делает его более управляемым. Я говорю с моей спины или есть какой-то смысл в моих мыслях?

Answer 1

Вы назвали это сообщение как вопрос SOA, но ваш дизайн не что иное, как. У вас есть тесно связанное приложение, в котором каждый из компонентов имеет глубокое знание других. На самом деле это объект с прямой ссылкой.

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