Какие есть источники, помогающие понять бизнес-логику проекта?

Question

[Егор Полянский]

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

Comments

[mxelgin]

Начинать надо с изучения паттернов.
Структура проекта строится через архитектурные паттерны - почитайте луковичную архитектуру
https://metanit.com/sharp/mvc5/23.1.php

выделют 3 базовые концепции, слой бизнес логики, слой приложения, слой домена.
концепций может быть больше в зависимости от приложения.

у каждой концепции есть свои фундаментальные задачи.

поначалу будет сложно понимать почему какой то класс должен быть именно там. Берите в руки ИИ и закидывайте вопросами, пока руку не набьете.

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

https://metanit.com/sharp/patterns/1.1.php

[aleks-th]

Ты главное начни, и сделай что-то полезное хотябы для трех калек, а все что тебе нужно само в процессе прийдет, и как раз будут приходить нужные вопросы и нужные ответы.
А так теоретически будешь всякие варианты перебирать, и никогда не начнешь даже... Знаю много людей кто вот так уже лет 10 планирует но ничего так и не начал.
А кто начал , пусть сначала криво или косо, потом выровнялось а , в итоге их проекты начали работать.

[Егор Полянский]

mxelgin, спасибо огромное!

[Егор Полянский]

aleks-th, вы правы, просто знать бы с чего вообще стоит начать для понимания

[mxelgin]

Егор Полянский, как все, с калькулятора)

[Adamos]

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

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

Answer 1

[VoidVolker]

Документация по самому проекту и его архитектуре в частности. Заказчик ставит задачу, на основе этой задачи разрабатывается ТЗ, а на основе ТЗ - частное ТЗ со всеми деталями проекта, в том числе и архитектурой. Вот вам несколько примеров:

Схема алгоритма

CAS, Central Authentication Service

Бизнес-логика приложения

Схема логики приложения

Вот ещё один отличный пример: описание структуры JSON - https://www.json.org/json-ru.html

Comments

[Егор Полянский]

А есть ли какие-либо информационные ресурсы, позволяющие разобраться в построении таких схем? Проект я пишу для себя, следовательно, структуру стараюсь выстроить сам.

[mxelgin]

То что вы показали это методология разработки Contract First, где сперва работа архитектора потом работа программиста. Разработчику лучше начинать изучать методологию Code First где сперва код потом архитектура. При правильном подходе паттернов программирования код превращается в расширяемую архитектуру и поддерживать такой проект легче.

[mxelgin]

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

[VoidVolker]

Егор Полянский конкретной леитературы не подскажу. Ищите по теме "проектирование и разработка ПО", "архитектура ПО". Ну а умение документировать, в т.ч. рисовать схемы придёт с опытом.
mxelgin, ну, это я просто привёл несколько примеров документации. Кстати, второй вариант как раз Contract First, а третий уже большей частью Code First (в конце разработки решили полностью поменять дизайн GUI и частично его логику). А так принципиальной разницы нет что раньше делать. В любом случае, если сначала рисовать/документировать схему/архитектуру, то по мере реализации в коде её 100% придётся править/дорабатывать в силу тех или иных причин.

Answer 2

[Zanak]

Однозначного рецепта нет.
Самый простой случай: вы строите проект на основе какого - либо фреймворка, и подтягиваете другие возможности, прежде всего БД, может быть, редиску или кролика, в качестве вспомогательных элементов для реализации задач проекта. Здесь все просто - фреймворк определяет размещение, количество и наполнение файлов. Если речь о web фреймворках, и количество страниц заметное, то, не возбраняется разложить ендпойнты по пакетам, согласно их логической близости.
Случай посложнее - монолитный сервис. Здесь в дело вступает декомпозиция по зонам ответственности, авторизация и регистрация, контроль прав, работа с данными проекта, обработка запросов, мониторинг, статистика, логгирование и так далее. Здесь, я, обычно, разделяю код по пакетам, чтобы не смешивать задачи, и сохранять его "обозримость".
Если, например, вы рассматриваете микросервисный проект, где подбираете инфраструктуру, и с помощью отдельных процессов выстраиваете взаимодействие между элементами, то, каждый микросервис, по сути, является отдельным приложением, которое может разделять, а может и нет, кодовую базу предметной области с другими.
Коллеги вспомнили о структурных паттернах, но, позволю себе обратить внимание на то, что данные шаблоны не регламентируют разделение кода по файлам. В них речь идет исключительно о способах решать конкретные проблемы.
Если смотреть на вопрос со стороны ТЗ, то, я стараюсь выделять минимальные смысловые части, и реализовывать их, как сочту правильным/удобным. Например, написано: работа пользователя с данными возможна только после авторизации, новые пользователи обязаны пройти процедуру регистрации. Из этого вытекает такая последовательность реализации: создаем миграцию для создания таблицы пользователей, создаем процедуру регистрации, создаем процедуру проверки данных авторизации, организуем хранение информации об авторизованных пользователях "кто онлайн". Миграции, как правило, хранятся пофайлово, манипуляция с учетками, может, относится к работе с объектом "пользователь", контроль прав может лежать в отдельном пакете, и подключаться по необходимости.

На мой взгляд, получается, как-то так.