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

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% придётся править/дорабатывать в силу тех или иных причин.