С чего начинать проектировать приложение?
===========================================

 Вообщем нет опыта в создании, сложным приложений, поэтому не могу понять с чего начинать его создавать? Для начала я выбрал технологии - PHP+MySQL и JS/jQuery, ибо для SPA не дорос.  
  

Приложение будет включать в себя мини CRM со средним множеством функций. Для себя я разбил этот проект на 4 части. В голове есть приблизительная архитекрута приложения, но опять же - с чего начинать в начале - загадка.  
  
1. Front-end
2. Back-end
3. Data
4. Misc

  
  

В начале я думал, сделать фроненд и потом начинать прикручивать функции к нему и работать с базой. Или в начале база потом бекенд и потом уже фронтед? Вообщем запутался. 

 Предположим, что с будущей функциональностью Вы определились. Тогда Вы точно знаете, кто или что будет поставлять данные, и кто/что будет их потреблять.   
  

Теперь выясните, кто будет обращаться к вашей системе, чтобы передать или забрать данные, а к чему будет обращаться Ваша программа. Те системы или пользователи, которые обращаются к программе сами, нарисуйте схематически на листе бумаги вверху. Те, к которым будет обращаться программа (включая БД), - снизу.   
  

Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API - это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем UI. Объедините все прямоугольники с API и обзовите слоем сервисов.  
  

Для систем, нарисованных снизу, укажите компоненты, которые будут отвечать за доступ к этим системам. Объедините все эти компоненты одним контуром и обзовите слоем доступа к данным.  
  

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

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

Получите логическую архитектуру. Разбросайте слои по серверам - получите физическую архитектуру.  
  

А дальше - детально прорабатывайте каждый маленький квадратик. Всё. 

 Сначала нужно расписать функционал приложения по пунктам: составить список тех функций, которые будут у приложения. Далеко в будущее заходить не надо, так как планы могут поменяться.  

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

Суть в том, что на каждом этапе у тебя должно быть законченное, рабочее приложение. Разница между этапами — степень проработки деталей функционала приложения. Это метод прогрессивного джипега :) Или agile.  

Чтобы понять, с чего начать, нужно посмотреть на приложение глазами пользователя: пользователь заходит на сайт, видит витрину товаров, видит описание у товара, цену, другие параметры, кнопку купить и т. д. То есть нужно реализовывать сценарии поведения пользователя. Можно даже acceptance-тесты накатать — помогает собрать мысли. 

 1. ТЗ  

2. Мокапы страниц  

3. Базовая архитектура приложения  

4. Реализация задачи с ТЗ  

5. goto 4 

 Проектирование нужно начинать с архитектуры. Основная идея - разбить систему на модули, каждой из которых выполняет свою задачу (single responsibility principle). Каждый модуль содержит компоненты. Компоненты в модулях сильно связны (cohesion) и слабо связаны (coupling). Каждый составной элемент - чёрный ящик, куда подаётся и выводится информация. Для устойчивости нужно интерфейс у этих ящиков документ документировать. Для построения API рекомендую building apis you won't hate.   
  

Начинайте проектировать сверху, а имплементировать - снизу.   
  

Ещё пара, но это уже advanced и немного мимо кассы ... вместо наследования используйте композицию. Поймите принципы ООП и ФП, используйте иммутабельность там, где нужно часто проверять, изменились ли данные... 

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

сделай например для начала заготовку, авторизацию (простой интерфейс + табличку в базе), потом добавление задачи в црм (+ табличку для нее), для начала можно с простейшим дизайном.  
  

Тебе сейчас нужно просто начать чтото делать. И делать понемногу все и фронтенд и бекенд и базу. Не бойся потом все можно отрефакторить/переделать. У тебя мало опыта чтобы сразу сделать хорошую архитектуру, но это не значит что нельзя начинать.   
  
**И то что было в начале уродцем постепенно превратится в курицу**, *несущую золотые яица*   
  

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

Советую сразу использовать какой нибудь php фреймворк, так хотя бы не придется ломать голову какую архитектуру должен иметь сервер и многие вещи будут уже готовы.   
  

Успехов. 

 Начните с создания простых приложений. 

 Ну как тебе сказать?! Сначала бизнес логика, потом предметная область, потом реализация предметной области в классах (ER диаграмма) что даст представление о БД которая разрабатывается после и на основе предметной области. Далее мигрируем диаграмму БД в код для конкретной СУБД. потом классы предметной области дополняются функциональностью и параллельно разрабатывается визуализация (фронт-энд). Потом наступает момент интеграции где предметная область интегрируется с БД и фронт-энд интегрируется с бэк-эндом и все уходит на тестирование. Как правило это все разрабатывается в один момент времени потому что работает команда, а если же трудишься и стараешься сам, то надо распределять время и заниматься часть дня тем, часть дня сем, и еще часть дня вот этим и так по кругу стремясь использовать спиральный метод разработки ПО с принципами Agile. Водопад не рекомендую. 

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

 Начинай с hello world. А если серьезно реализуй базовую архитектуру, или возьми готовое архитектурное решение какого нибудь фреймворка типо laravel symfony или zend. Пиши для себя задачи и выполняй их постепенно 

 Я начинаю с API, (HTTP REST API в случае web) и структуры данных. 

 С Архитектуры!!!!