Что такое TDD и DDD
#терминология
После поста выше про разработчика мне стали приходить в личку сообщения на тему "вы, наверно, опечатались, не DDD, а TDD". Так вот, я не опечаталась - я написала именно то, что хотела.
А теперь разбираемся, что же такое TDD и DDD:
TDD (Test Driven Development) относится к подходам к разработке. Смысл его в том, что сначала пишется тест, покрывающий какой-то один (самый простой) пользовательский сценарий, и только затем пишется код, который проверяется по написанному ранее тесту. И так, постепенно наращивая сложность сценариев, разрабатывается весь функционал. При таком подходе разработчики фокусируются на необходимом функционале, а не функционале "на будущее", ведь главной задачей становится прохождение ранее написанного теста, а также перестают бояться вносить правки в систему, потому что с тестами это делать безопасно: их предполагается запускать примерно каждые несколько минут, и если правка сломала код, то тесты об этом незамедлительно сообщат.
DDD (Domain Driven Design) относится к архитектуре системы, это предметно-ориентированное проектирование. При таком подходе разработчик должен хорошо понимать предметную область бизнеса и бизнес-процессы в самой компании, чтобы выстроить архитектуру системы в соответствии с ними. В этом главный плюс DDD: программирование — это перенос законов бизнеса в код. Если человек не понимает законов и правил бизнеса, то это отразится в коде и с этим кодом можно будет работать при создании какой-то домашней страницы, но в сложных системах он быстро станет неподдерживаемым.
#терминология
После поста выше про разработчика мне стали приходить в личку сообщения на тему "вы, наверно, опечатались, не DDD, а TDD". Так вот, я не опечаталась - я написала именно то, что хотела.
А теперь разбираемся, что же такое TDD и DDD:
TDD (Test Driven Development) относится к подходам к разработке. Смысл его в том, что сначала пишется тест, покрывающий какой-то один (самый простой) пользовательский сценарий, и только затем пишется код, который проверяется по написанному ранее тесту. И так, постепенно наращивая сложность сценариев, разрабатывается весь функционал. При таком подходе разработчики фокусируются на необходимом функционале, а не функционале "на будущее", ведь главной задачей становится прохождение ранее написанного теста, а также перестают бояться вносить правки в систему, потому что с тестами это делать безопасно: их предполагается запускать примерно каждые несколько минут, и если правка сломала код, то тесты об этом незамедлительно сообщат.
DDD (Domain Driven Design) относится к архитектуре системы, это предметно-ориентированное проектирование. При таком подходе разработчик должен хорошо понимать предметную область бизнеса и бизнес-процессы в самой компании, чтобы выстроить архитектуру системы в соответствии с ними. В этом главный плюс DDD: программирование — это перенос законов бизнеса в код. Если человек не понимает законов и правил бизнеса, то это отразится в коде и с этим кодом можно будет работать при создании какой-то домашней страницы, но в сложных системах он быстро станет неподдерживаемым.