На этот вопрос я бы ответил так: начинать проектирование надо не со схемы базы данных, и не с бизнес-логики. Конечно, я и сам обычно начинаю создание именно с проектирования схемы БД, но в целом тогда, когда предметная область мне знакома и ясна.
Вы создаете приложение, а значит вам необходимо знать и понимать кто будет использовать вашу систему и, главное - какие проблемы будет решать ваш программный продукт. И это очень важно!
Например: вам необходимо автоматизировать деятельность платной библиотеки. Использовать ее будут администратор, сотрудник библиотеки и читатель.
Далее, нам необходимо решить какие сценарии использования (так называемые use case) будет реализовано в нашем приложении, т.е. как эти люди (actor) будут использовать нашу систему.
Администратор - управление сотрудниками библиотеки, учет книг;
Сотрудник библиотеки - выдача книг, возврат книг, продажа абонементов;
Читатель - резервирование книг, продление книг, оплата книг и т.д.
А вот когда мы понимаем, кто и как будет использовать наш программный продукт, тогда мы уже можем приступать к реализации бизнес-слоя. Причем не обязательно, что вам необходимо строить полноценную модель предметной области, вы можете ее не строить, удобный шаблон реализации бизнес-слоя - это сценарий транзакции (Transaction Script).
Если все же решили делать модель предметной области, то тут необходимо решить какая она будет, анемичная (anemic ) или богатая (rich). В первом случае вся логика сосредоточена в сервисах бизнес-слоя, а сами сущности предметной области простые контейнеры данных, которые обычно один в один совпадают со схемой базы данных. Во втором случае, основная логика бизнес-поведения сосредоточена в классах бизнес-сущностей.
Ну как-то так...
Простой
Простой
Средний
Простой
Средний
Простой
