Однажды я решила начать смотреть на системы как архитектор, и искала, что почитать. Одна из книг, которая попалась на просторах Интернета:
📚 Domain Driven Design. Предметно-ориентированное проектирование
🙏 Эрик Эванс
Если честно, то новой информации про архитектуру я в ней много не нашла. Зато, как системный аналитик, еще раз пересмотрела подходы к проектированию, структурировала знания, и начала осознанно использовать рекомендации из нее.
Цитаты:
📝 Проект сталкивается с серьезными проблемами, когда в нем отсутствует единый язык коммуникаций. У специалистов в предметной области свой жаргон, у разработчиков - свой. Терминология повседневных дискуссий оторвана от терминологии, внедренной в код. Возникают сложности перевода.
Вывод: бизнес-сущности в реальности и в модели стоит именовать одинаково, создавать общий язык для описания предметной области между заказчиками и разработчиками
📝 Если архитектура программы или некая ее центральная часть не соответствует модели предметной области, то такая модель практически бесполезна, и правильность работы программы тоже можно поставить под сомнение
Вывод: косяки бизнес-анализа предметной области заказчика, могут превратить труды разработчиков не в рабочую систему, а в бесполезные строки кода
📝 Разбейте сложную программу на уровни. Внутри каждого уровня разработайте связанную структуру, полагающуюся на нижние уровни и зависящую только от них.
Вывод: при описании сценариев использования системы пробовать выделять логические модули, которые потенциально могут быть переиспользованы в других частях программы. Аналитики должны давать подсказки разработчикам, так как видят систему шире, за рамками одной задачи.
В книге есть примеры Java-кода. Кому сложно - пропускайте. Разобраны интересные практические кейсы. Большая часть книги написана простым языком. Рекомендую 😉
📚 Domain Driven Design. Предметно-ориентированное проектирование
🙏 Эрик Эванс
Если честно, то новой информации про архитектуру я в ней много не нашла. Зато, как системный аналитик, еще раз пересмотрела подходы к проектированию, структурировала знания, и начала осознанно использовать рекомендации из нее.
Цитаты:
📝 Проект сталкивается с серьезными проблемами, когда в нем отсутствует единый язык коммуникаций. У специалистов в предметной области свой жаргон, у разработчиков - свой. Терминология повседневных дискуссий оторвана от терминологии, внедренной в код. Возникают сложности перевода.
Вывод: бизнес-сущности в реальности и в модели стоит именовать одинаково, создавать общий язык для описания предметной области между заказчиками и разработчиками
📝 Если архитектура программы или некая ее центральная часть не соответствует модели предметной области, то такая модель практически бесполезна, и правильность работы программы тоже можно поставить под сомнение
Вывод: косяки бизнес-анализа предметной области заказчика, могут превратить труды разработчиков не в рабочую систему, а в бесполезные строки кода
📝 Разбейте сложную программу на уровни. Внутри каждого уровня разработайте связанную структуру, полагающуюся на нижние уровни и зависящую только от них.
Вывод: при описании сценариев использования системы пробовать выделять логические модули, которые потенциально могут быть переиспользованы в других частях программы. Аналитики должны давать подсказки разработчикам, так как видят систему шире, за рамками одной задачи.
В книге есть примеры Java-кода. Кому сложно - пропускайте. Разобраны интересные практические кейсы. Большая часть книги написана простым языком. Рекомендую 😉