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

Question

[CAMOKPYT]

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

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

Желательно в контексте любого современного ЯП, так чтобы можно было посмотреть на код. В идеале это нечто вроде, когда человек рассказывает какой у него был проект, какое было базовое ТЗ, как он рассуждал, что сделал, как менялось ТЗ, какие вещи он сделал правильно, какие неправильно, почему и на что надо обратить внимание в будущем.

Answer 1

[Алексей Елецкий]

По-моему таких материалов пока нет и даже не предвидится. Подобный опыт тяжело формализируется. Вообще, почти нигде не учат «как решать задачи» :-)

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

Также можно почитать Феномен науки. Кибернетический подход к эволюции.

Comments

[Viktor Vsk]

Мне кажется, что мало того, что формализуется сложно, так еще и пока формализуешь, так это уже трижды станет неактуально (такие вот нетиповые структуры). По разным причинам. На то екоммерсы и формализованы, что жили, живут и будут жить.

А из просто технического вот это поразило когда-то своей простотой и гениальностью.

[Алексей Елецкий]

@victorvsk мельком посмотрел книгу, выглядит годно, на досуге почитаю. Большое спасибо.

По поводу устаревания не согласен. Это смотря что формализировать, если какие-то низкоуровневые фичи, до конечно устареют. А если то, что надо, то не должно :-) Сейчас мало кто ориентирован на долгосрочный результат, оттого и обучающие материалы, которые на виду, не затрагивают такие моменты. Может даже есть что-нибудь толково написанное по теме, но им пользуются только матёрые спецы, а отсльные могут и просто не знать.

Answer 2

[Максим Гаврилов]

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

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

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