Как разрабатывать нетиповую архитектуру?

Допустим есть типовой проект - CRM, интернет магазин, СЭДО. Если человек хоть раз чем-то таким пользовался, то он уже имеет неплохое представление о том какие есть сущности и как их описать в коде. Если же человек никогда не пользовался, то обычно можно довольно легко загуглить какие бывают типовые составляющие для проекта. Но иногда бывает так что проект нетиповой, он может быть как нечто среднее между несколькими типовыми, так и вообще нечто достаточно уникальное, чтобы писать фундаментальные вещи с нуля. Собственно интересны любые источники информации где можно было бы подсмотреть следующее:
  • Какие вопросы задавать заказчику, на чем акцентировать внимание
  • Проработка абстракций для сущностей
  • Собственно маппинг сущностей в код
  • Предупреждение узких мест в будущем, рефакторинг


Желательно в контексте любого современного ЯП, так чтобы можно было посмотреть на код. В идеале это нечто вроде, когда человек рассказывает какой у него был проект, какое было базовое ТЗ, как он рассуждал, что сделал, как менялось ТЗ, какие вещи он сделал правильно, какие неправильно, почему и на что надо обратить внимание в будущем.
  • Вопрос задан
  • 2500 просмотров
Пригласить эксперта
Ответы на вопрос 2
Tiendil
@Tiendil
Разработчик ПО.
По-моему таких материалов пока нет и даже не предвидится. Подобный опыт тяжело формализируется. Вообще, почти нигде не учат «как решать задачи» :-)

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

Также можно почитать Феномен науки. Кибернетический подход к эволюции.
Ответ написан
thestump
@thestump
программист PHP
Я считаю, что при проектировании не типовых составляющих проекта надо обращать внимание на предметную область. Как вы писали в вопросе при типовых составляющих информацию о предметной области доступна и при некоторых случаях доступна реализация предметной области которую можно подсмотреть. А когда предметная область еще не изучена то лучшим советом будет изучение предметной области и обсуждение с заказчиком того, какое представление будут иметь фрагменты предметной области.

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

В качестве литературы тут думаю подойдет любая литература про разработку через предметную область (DDD).
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы