Qualidade
Alexandre Brandão Lustosa
SOLID
Domain Driven Design
A MundiPagg é um gateway de pagamento único desenvolvido para transformar a indústria de pagamentos online brasileira.
Um rápido crescimentoSomos uma companhia jovem, mas com bastante experiência no mercado.
Em menos de três anos, a MundiPagg já processava 30 % do varejo online brasileiro.
Ano passado processamos cerca de R$ 6 bilhões e esperamos mais de R$ 15 bilhões em 2015.
Em 2014, recuperamos cerca de
R$ 87,5 milhõespara nossos clientes
PLATAFORMA ONE
MUNDIPAGG
Nosso ecossistemaA MundiPagg é uma companhia da DLP que objetiva ser um canal para a adquirência.
Ecossistema DLP
ONLINE
FÍSICO
ADQUIRENTE
GATEWAY DE PAGAMENTOS
TEF / GATEWAY OFFLINE
PROCESSADORA
Pagar.me
Nossos clientes
LOJAS DEPARTAMENTO MODA ENTRETENIMENTO ALIMENTOS
Temos mais de 1500 lojas em nosso portfólio, algumas delas são as maiores marcas brasileiras e internacionais.
ÓLEO TV
Faça parte do nosso time!
"A única maneira de fazer um excelente trabalho é amar o que você faz." (Steve Jobs)
Faça parte do nosso time!
"A única maneira de fazer um excelente trabalho é amar o que você faz." (Steve Jobs)
Alexandre Brandão
{ Microsoft C# .Net Solution Developer, C++ Linux Developer, C/C++ Embedded Programmer }
<contatos> <twitter>
@abrandaolustosa </twitter> <skype>
[email protected] </skype></contatos>
Analista Desenvolvedor SêniorArquiteto de Sistemas
/* Linkedin: abrandaol*/
curl -data “experiencia=16_anos&motivacao=inovacao%20e%20pesquisa” https://www.mundipagg.com
{ “Agenda” : {
“Qualidade” : “Pense, Modele, Teste, Faça”,“DDD” : “Domine o Domínio”,“SOLID” : {
“Conceito” : “Motivação”,“Interface” : “Programe para Interface”“Aplicação” : “Definição e Uso”
}}
} /* “Você pode encarar um erro como uma besteira a ser esquecida, ou como um resultado que aponta uma nova direção.” */
( Ran
king
)
http://blog.codeeval.com/codeevalblog/2015#.VWW9dbznreQ=
[ DART ]
{ Qualidade de Software }
[ Satisfação do Cliente ]
Tempo / Entregas
Custo Qualidade
Requisitos
Desenvolvimento
Implantação
*Ciclo e Processo Desenvolvimento;
*Ciclo e Processo Desenvolvimento;
Requisitos
Desenvolvimento
Implantação
• Rollback de publicação;• Indisponibilidade;• Insatisfação do cliente;• Riscos no negócio;• Prejuízo financeiro;
( Modelo V )Requisitos
Recursos
Arquitetura
Regras de Negócio
Desenvolvimento
Aceite do Cliente
Teste de Sistema
Teste de Integração
Teste Unitário
Plano
Plano
Plano
Plano
Valid
ação
Validação
<risco>Foco na primeira entrega?
</risco>
if(redução_de_risco ==
foco_na_primeira_entrega){throw new
Exception(“FALHA”);}else{
return “SUCESSO!!! :)”;}
{“Produtividade”:
“Seu time é ágil?”,}
- Preciso ser ágil!• Requisitos • Planejamento• BluePrint• Documentação• RoadMap
• Deploy• Monitoramento• Controlde de
Incidentes
{ Modelo V / Desenvolvimento Ágil}
T=> Time + Cultura + Pessoas + Comunicação + Compromisso
T=> Tecnologia + Documentação + Investimento + Foco no Cliente
{ Domain Driven Design }
Projeto Orientado a Domínio
“Atacando as complexidades no coração do software”(Eric Evans)
[ Objetivos]• Alinhamento as regras de negócio
• Favorecer reutilização de código
• Mínimo de acoplamento
• Independência de Tecnologia
[ Modelos segundo Eric Evans]
• O modelo e o coração do design dão forma um ao outro
• O modelo é a espinha dorsal de uma linguagem utilizada pelos desenvolvedores
• O modelo é um conhecimento destilado
<Objetivo_do_DDD>Criar softwares melhores concentrando-se em um modelo de domínio e não na tecnologia.
</Objetivo_do_DDD>
{ Pilares da Orientação a Objeto }
• Herança
• Polimorfísmo
• Encapsulamento
• Abstração
{ Padrões de projeto }Padrões de criação
• Abstract Factory• Builder• Factory Method• Prototype• Singleton
Padrões estruturais
• Adapter• Bridge• Composite• Decorator• Façade (ou Facade)• Flyweight• Proxy
Padrões comportamentais
• Chain of Responsibility• Command• Interpreter• Iterator• Mediator• Memento• Observer• State• Strategy• Template Method• Visitor
[ Modelo Conceitual ]
A modularidade se torna mais crítica a medida que do design cresce e se torna mais complexo.
[ Mod
elo
Conc
eitu
al ]
[ Isolando o Domínio ]
Cada conceito do modelo de domínio deve refletir um elemento da implementação.
{ SOLID }É um acrônimo para:
- Single responsibility- Open-closed- Liskov substitution- Interface segregation- Dependency inversion
Criado por Michael Feathers como “Firt Five Principle”, e nomeado como SOLID por Robert C. Martin
{ SOLID }
/*São cinco princípios básicos da orientação a objeto
*/
{ Single Responsibility }< Principio da Responsabilidade Única />
Uma classe deve ter um, e somente um, motivo para mudar
{ Single Responsibility }
public class Departamento { public void calculaNotaFiscal() { // seu código para calculo da nota fiscal } public void calculaPagamentoDeFuncionarios() { // seu código para cálculo do pagamento } public void verificaInadimplenciaDeClientes() { // seu código para a verificação de inadimplência }}
public class NotaFiscal { public void calculaNotaFiscal() { // seu código para cálculo da nota fiscal } }
public class CalculadoraDePagamento { public void calculaPagamentoDeFuncionarios() { // seu código para cálculo do pagamento } }
public class VerificadorDeInadimplencia { public void verificaInadimplenciaDeClientes() { // seu código para a verificação de inadimplência } }
{ Não respeita SOLID }
{ Open-Closed }
< Princípio Aberto-Fechado />
Você deve ser capaz de estender um comportamento de uma classe, sem modificá-lo.
{ Open-Closed }public abstract class Shape { public abstract double Area();}
public class Rectangle : Shape { public double Width { get; set; } public double Height { get; set; } public override double Area() { return Width*Height; }}
public class Circle : Shape{ public double Radius { get; set; } public override double Area() { return Radius*Radius*Math.PI; }}
public class DrawProcess{
public static double Area(Shape[] shapes){
double area = 0; foreach (var shape in shapes) { area += shape.Area(); }
return area; }}
{ Liskov Substitution }
< Princípio da Substituição de Liskov />
As classes derivadas devem ser substituíveis por suas classes base.
{ Liskov Substitution } public class BaseClass { public string ProductName { get; set; } public virtual void Shipping(){ } public virtual void Order(){ } }
public class DerivedClass :BaseClass{ public string CustomerInfo { get; set; } public void DeliveryAddress(){ }
public override void Shipping(){ base.Shipping(); } public override void Order(){ base.Order(); } }
public class Present { public static void Main() { var baseClass = new DerivedClass(); baseClass.ProductName = “XBox"; baseClass.Shipping(); baseClass.Order(); } }
{ Interface Segregation }
< Princípio da Segregação da Interface />
Muitas interfaces específicas são melhores do que uma interface única.
{ Dependency Inversion } < Princípio da inversão da dependência />
Dependa de uma abstração e não de uma implementação.
{ Dependency Inversion }
public interface IWorker {public void work();
}
public class Worker implements IWorker{public void work() {
// ....working}
}
public class SuperWorker implements IWorker{public void work() {
//.... working much more}
}
public class Manager {IWorker worker;
public void setWorker(IWorker w) {worker = w;
}
public void manage() {worker.work();
}}
class Manager {IWorker worker;
public void setWorker(IWorker w) {worker = w;}
public void manage() {worker.work();}}
{ Dependency Inversion }
Containers de injeção de dependência:
Exemplos: Microsoft Unity, Ninject, Spring, Spring.net, etc...
Uso:1) Registro da interface e tipo2) Resolve e carrega o tipo registrado para a interface ou identificador
{ Container de DI / IOC – Microsoft Unity }
public void RegisterTypes(){var container = new UnityContainer();container.RegisterType<ILivro, Livro>();
}
public void Process(){var livro = container.Resolve<ILivro>();
//Do something}
Registro do tipo
Resolve o tipo
{ ! }
{Seja hoje um pessoa
melhor do que você foi ontem
}
Pesquise...
Pesquise...Estude...
Pesquise...Estude...
Domine...
Pesquise...Estude...
Influencie...
Domine...
Obrigado :)
Perguntas?
Obrigado :)
E-mail: [email protected]
Skype: [email protected]
Twitter: @abrandaolustosaLinkedIn: abrandaol