Я конечно дико извиняюсь и снимаю шляпу перед стараниями автора. Но, честно, не понимаю, зачем интерпретировать документацию? Возможно я не уловил какой-то смысл, тогда прошу прощения, но вроде как чего-то нового в статье не описано, а как создавать шаблоны есть и в документации..
Верно подмечено, но, на собственном проекте Вы как Джеймс Бонд, есть лицензия на все: любой рефакторинг, любые реорганизации проекта, в любой момент Вы даже можете пересмотреть кардинально архитектуру. И за n-ое количество времени все переделать.
Другой момент, это производственный код, который далеко не всегда можно отрефакторить при появлении первых неприятных «запахов». Собственно, это, на мой субъективный взгляд чаще всего и является причиной перехода от Common, до «да, положи пока в Common, позже зарефакторим и почистим его..»
Хотел бы добавить еще на подумать, вопрос общего кода между n «смысловых» единиц, какой-нибудь Common… скорее всего в перспективе превратится в отстойник всего и вся со всех слоев, что так или иначе не удалось положить в «смысловой». Плюс, при организации кода по «стеку» внутри «смыслового» подхода, неявно наталкивает новаторов на использование разных «стековых» организаций… но, все конечно субъективно
Это Вам спасибо за статью!
Мне кажется в этот список должен был бы еще попасть, как минимум:
https://andrewlock.net/
и на мой субъективный взгляд:
https://www.stevejgordon.co.uk/
Я конечно дико извиняюсь и снимаю шляпу перед стараниями автора. Но, честно, не понимаю, зачем интерпретировать документацию? Возможно я не уловил какой-то смысл, тогда прошу прощения, но вроде как чего-то нового в статье не описано, а как создавать шаблоны есть и в документации..
Другой момент, это производственный код, который далеко не всегда можно отрефакторить при появлении первых неприятных «запахов». Собственно, это, на мой субъективный взгляд чаще всего и является причиной перехода от Common, до «да, положи пока в Common, позже зарефакторим и почистим его..»