I have joined Anti-IF Campaign

The Domain Driven Design, or just DDD, was created by Eric Evans and consists of the alignment of business and code construction, that way, the code generated must be the exact reflection of the business. For instance, if your business determines that all clients invoice must be paid until the deadline, that scenario should be the same in code design, like probably a Client class, an Invoice class with a deadline attribute, and a service class with a pay() method.

This is a very important characteristic of DDD because that way all people involved in this scenario can clearly communicate with each other. This process is called as Ubiquitous Language and it provides some good reasons to do it, like:

  • The code reflects business and business refects code.
  • Increase the code reuse, once that a specific domain can be used in different parts of an application.
  • Loose coupling: a well-done model can operate independently in some cases since it represents a specific business piece.
  • It is technology independent: a ubiquitous language it’s not concerned about technological choices, but in how business and technical areas will understand each other. In other words, it is concerned with how business logic will be interpreted and reflected in the code.

It is easy to find developers that don’t like that business stuff and prefer to code like a freaking machine. But in DDD this doesn’t work. Why? This answer is very simple: programmers are an important piece of this puzzle and they are called as hands-on modelers. Like I said before, all the team must be involved in the process. All the parts must be aligned!!!!!!! It doesn’t matter if the business and the architectural team are tightly aligned and the hands-on team doesn’t care about it. The result will be something that doesn’t represent a model and consequently doesn’t represent a domain!

Continue lendo

Vamos falar sobre o método equals()? Embora alguns programadores desdenhem a necessidade de implementação do método equals() em suas classes, essa prática se faz extremamente necessária para o correto funcionamento deste recurso. Se olharmos na documentação do método equals() da classe Object, será fácil identificar o porquê se faz necessário sobrescrever o método de comparação de objetos nas suas entidades.

Se liga no drama que acontece aqui, padauã. A comparação é feita somente levando em consideração a referência de dois objetos, ou seja, essa comparação será verdadeira se você fizer, por exemplo:

Continue lendo

Muitas empresas e responsáveis de TI buscam constantemente agregar valor nos produtos e serviços entregues de várias maneiras, seja por meio de ciclos de entrega contínuos com pequenos pedaços funcionais de software, pela criação de aplicações infladas e cheias de recursos que muitas vezes sequer serão utilizados, desenvolvendo soluções baseadas na orientação a serviço, entre outras. Fato é que, independente da estratégia de atuação do departamento de TI, agregar valor não é uma tarefa fácil e requer, muitas vezes, grande esforço por parte dos envolvidos no projeto. Com a arquitetura orientada a serviços não seria diferente, pois esta, além de trazer grandes mudanças no paradigma de desenvolvimento de software, influencia diretamente na forma de gerenciar e governar TI na corporação, propondo desafios tecnológicos, operacionais, de infraestrutura, entre outros.

Continue lendo

É certo que o paradigma de sistemas computacionais está em constante evolução. Muitas destas evoluções vêm para aumentar a produtividade do processo de desenvolvimento de software, diminuir custos operacionais, estabelecer diretrizes de governança de TI, entre outros. O problema é que com essa miscigenação de conceitos, frameworks e metodologias, nem sempre é possível manter o alinhamento estratégico entre o negócio e a TI,  por falta de maturidade nos conceitos utilizados, disparidade de interesses entre os especialistas de negócio e os especialistas de TI ou simplesmente por não ter maturidade para fazer as engrenagens se encaixarem e fazer o mecanismo funcionar adequadamente, ocasionando muitas vezes, por exemplo, em cenários semelhantes às salas de guerra.

Deixar de enxergar a TI como um segmento separado do negócio e vice versa, é algo relativamente custoso para muitos profissionais na nossa área, porém, o paradigma de arquitetura orientada a serviço surge para fortificar ainda mais a necessidade de paridade entre o negócio e a TI para um bem maior, longe dos egos e holofotes, uma vez que para se alcançar as premissas de SOA é necessário que ambos os setores trabalhem em conjunto do início ao fim. Pensando nisto, hoje abordaremos os objetivos e benefícios estratégicos que a metodologia SOA pode proporcionar. Vamos nessa!

Continue lendo

Atualmente as empresas estão cada vez mais dependentes da TI para alcançar seus objetivos de negócio, obter resultados positivos e atingir um diferencial no mercado. Desta forma, a tecnologia da informação deixou de ser apenas um provedor de serviços, cujas despesas devem ser controladas, e passou a atuar como um parceiro, com orçamentos voltados à estratégia do negócio e gerenciados como um investimento.

Ao longo desta transição, os planos de negócio das instituições ficaram cada vez mais complexos, obrigando a TI a desenvolver processos cada vez mais maduros, com ciclo de vida bem definido e levando em consideração outros marcos de regulação e modelos de gerenciamento. Com isso, surgiu a necessidade de implementar uma Governança de TI eficiente, a fim de transparecer o trabalho do departamento de tecnologia da informação, reduzir gastos, gerenciar riscos, agregar valor ao serviço e principalmente mensurar o retorno sobre o investimento em tecnologia.

Continue lendo