Sempre tive a visão que organizava mal a estrutura da aplicação, sem representar com clareza no código a intenção de negócio que motivava a existência dele; percebi que organizava a aplicação em torno de propósitos técnicos e confesso que é muito tentador seguir organizando dessa forma.
O artigo a seguir ressalta a importância em representar casos de uso como elementos explícitos na aplicação, caracterizado na seguinte afirmação: ‘a ausência de casos de uso deve ser considerado um mau cheiro’ (minha tradução). Além disso o artigo aborda aspectos arquiteturais na organização das dependências seguindo princípios consagrados.
https://joebew42.github.io/2021/10/23/use-cases-purpose-of-your-code
Ótimo artigo! Todo mundo já começou um projeto onde não há entidades definidas, apenas grandes controllers, que contém todas as regras de negócios e manipulam diretamente mecanismos de persistência. É muito mais fácil, rápido, e consequentemente tentador, programar de forma 100% concreta, sem pensar em divisão de responsabilidades e segregação dos elementos que compõem a aplicação. É exatamente isso que leva pessoas, erroneamente, a criticarem uma aplicação bem arquitetada: exige esforço, gera mais código e é mais difícil de se entender do que um programa procedural. Mal sabem elas que uma aplicação bem arquitetada tem menos erros, facilita futuras mudanças e a realização de testes unitários.
No início do texto você fala que sempre teve a visão que organizava mal a estrutura da aplicação, sem representar com clareza no código a intenção de negócio que motivava a existência dele. Alguns dizem que isso seria o design da aplicação, mas, como o Bob Martin fala em Clean Architecture, isso diz respeito à arquitetura, não existe separação entre design e arquitetura de software, elas são uma coisa só. Se analisarmos um projeto de um arquiteto de construções, ele detalha desde como o exterior da construção será, até os móveis e a decoração. Uma definição que eu gosto muito, e que casa perfeitamente com o artigo apresentado, é a do Ivar Jacobson em “Object-Oriented Software Engineering: A Use Case Driven Approach”, ele diz que arquitetura de software é a estrutura necessária para suportar os casos de uso do sistema.
Bob Martin, concisamente, explica o objetivo/razão da existência dos casos de uso dizendo: “casos de uso controlam a dança das entidades”. Tudo que não é entidade — objetos centrais do sistema — ou regra de negócio — regras ou procedimentos que geram ou economizam dinheiro — deve ser segregado do caso de uso através de uma interface.
O mais engraçado é que, para aqueles que realizam graduação na área de construção de software, uma das primeiras coisas a se aprender é sobre casos de uso e como modelá-los em UML. Infelizmente, aprender cedo não é uma garantia de entender o conceito em sua totalidade.