Bom dia ,venho submeter o 6º resumo do livro .

                                               65 á 74       

Esse tipo de classe tem uma característica bem procedural, fortemente sinalizada pela ausência de atributos e excesso do uso de métodos como funções (deposita e saca poderiam ser estáticos).

 Além disso, pode-se dizer que esta classe tem uma intimidade inapropriada com a classe Conta, pois conhece demais sua implementação interna.

 Repare que o método saca verifica primeiro se o saldo é maior que o valor a ser sacado, para, então, retirar o dinheiro.

Tópicos de Orientação a Objetos podemos unir a lógica de negócio aos dados de uma maneira simples, inserindo métodos na classe conta e removendo os que apenas acessam e modificam diretamente seus atributos.

Aqui mantivemos o getSaldo, pois faz parte do domínio.

 Também adicionamos algumas manipulações ao método saca, e poderíamos debitar algum imposto em cima de qualquer movimentação financeira no método deposita.

 Enriqueça suas classes com métodos de negócio, para que não se tornem apenas estruturas de dados.

Para isso, cuidado ao colocar getters e setters indiscriminadamente.

 Devemos encapsular os dados em atributos de objetos e, ainda, lembrar que a orientação a objetos prega a troca de mensagens (invocação de métodos) de maneira a concentrar as responsabilidades a quem pertence os dados. O

próprio Alan Kay, que cunhou o termo “programação orientada a objetos”, ressalta que “o termo foi uma má escolha, pois diminui a ênfase da ideia mais importante, a troca de mensagens”.

 Considere Domain-Driven Design Casa do Código a real necessidade dos getters e setters.

Por exemplo, a necessidade de um método setId para a chave primária torna-se discutível no momento em que um framework utiliza reflection ou manipulação de bytecode para ler atributos privados.

Algumas vezes, os getters e setters são, sim, necessários, e alguns patterns até mesmo precisam de uma separação de lógica de negócios dos respectivos dados.

 É muito fácil terminar colocando a lógica de negócio, que poderia estar em em nossas entidades, diretamente em Actions do Struts, ActionListeners do Swing e managed beans do JSF, transformando-os em transaction scripts.

Este modelo acaba ficando com um forte apelo procedural e vai diretamente na contramão das boas práticas de orientação a objetos e do Domain-Driven Design.

 Considere Domain-Driven Design Todo software é desenvolvido com um propósito concreto, para resolver problemas reais que acontecem com pessoas reais.

Todos os conceitos ao redor do problema a ser resolvido são o que denominamos domínio. O objetivo de toda aplicação é resolver as questões de um determinado domínio.

 Domain-Driven Design (DDD) significa guiar o processo de design da sua aplicação pelo domínio. Parece óbvio, mas muitos softwares não são projetados de acordo com o domínio em que atuam.

 Podemos perceber essa realidade analisando o código de diversos sistemas atuais, nos quais as entidades não condizem com a realidade dos usuários e são de difícil entendimento.

Segundo o DDD, é impossível resolver o problema no domínio do cliente sem entendê-lo profundamente.

 É claro que o desenvolvedor não quer se tornar um completo especialista na área do cliente, mas deve compreendê-la o suficiente para desenvolver guiado pelo domínio. Para isto acontecer, o ponto-chave é a conversa.

 Conversa constante e profunda entre os especialistas de domínio e os desenvolvedores. Aqueles que conhecem o domínio em detalhes devem transmitir conhecimento aos desenvolvedores.

 Juntos, chegarão a termos e vocábulos em comum, uma língua comum, que todos utilizem.

 Durante a conversa constante, cria-se um modelo do domínio (ou Domain Model).

É uma abstração do problema real, que envolve os aspectos do domínio que devem ser expressados no sistema, desenvolvida em parceria pelos especialistas do domínio e desenvolvedores.

 É este modelo que os desenvolvedores implementam em código, que deve ocorrer literalmente, item por item, como foi acordado por todos.

 Isto possibilita o desenvolvimento de um código mais claro, e, principalmente, que utiliza metáforas próprias do domínio em questão.

Seu programa deve expressar a riqueza do domain model.

Qualquer mudança no modelo deve ser refletida no código.

Caso o modelo se torne inviável para se implementar tecnicamente, ele deve ser mudado para se tornar implementável.

Esse processo não ocorre antes do início do projeto, mas é um trabalho constante, que deve ser revisitado a todo instante.

Praticando DDD, é comum encontrar situações em que o especialista e os desenvolvedores aprendem mais sobre o domínio e refatoram o código e suas entidades à medida que o projeto é desenvolvido e, por isso, práticas de Test Driven Design e refatoração são complementares a DDD.

 No DDD, seu código sempre será a expressão do modelo, que, por sua vez, é guiado pelo domínio.

 A principal literatura sobre Domain-Driven Design é o livro homônimo de Eric Evans.