O documento descreve as atividades e valores da empresa MundiPagg. Em menos de três anos, a MundiPagg processou 30% do comércio eletrônico brasileiro e R$6 bilhões em pagamentos em 2014. A empresa busca contratar novos funcionários que amem seu trabalho.

1. Qualidade
Alexandre Brandão Lustosa
SOLID
Domain Driven
Design

2. A MundiPagg é um gateway de
pagamento único desenvolvido para
transformar a indústria de pagamentos
online brasileira.

3. Um rápido crescimento
Somos 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.

4. Em 2014, recuperamos cerca de
R$ 87,5 milhõespara nossos clientes

5. PLATAFORMA ONE
MUNDIPAGG

6. Nosso ecossistema
A 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

7. 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

9. Faça parte do nosso time!
vagas@mundipagg.com
abrandao@mundipagg.com
"A única maneira de fazer um excelente trabalho é amar o que você faz."
(Steve Jobs)

10. Faça parte do nosso time!
querotrabalhar@stone.com
abrandao@mundipagg.com
"A única maneira de fazer um excelente trabalho é amar o que você faz."
(Steve Jobs)

11. Alexandre
Brandão
{ Microsoft C# .Net Solution Developer,
C++ Linux Developer, C/C++ Embedded Programmer }
<contatos>
<twitter>
@abrandaolustosa
</twitter>
<skype>
abrandao@mundipagg.com
</skype>
</contatos>
Analista Desenvolvedor Sênior
Arquiteto de Sistemas
/*
Linkedin: abrandaol
*/
curl -data “experiencia=16_anos&motivacao=inovacao%20e%20pesquisa” https://www.mundipagg.com

12. { “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.” */

13. http://blog.codeeval.com/codeevalblog/2015#.VWW9dbznreQ=

14. [ DART ]

15. { Qualidade de Software }

16. [ Satisfação do Cliente ]
Tempo / Entregas
Custo Qualidade

17. Requisitos
Desenvolvimento
Implantação
*Ciclo e Processo Desenvolvimento;

18. *Ciclo e Processo Desenvolvimento;
Requisitos
Desenvolvimento
Implantação
• Rollback de publicação;
• Indisponibilidade;
• Insatisfação do cliente;
• Riscos no negócio;
• Prejuízo financeiro;

19. ( 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
Validação
Validação

20. <risco>
Foco na primeira entrega?
</risco>

21. if(
redução_de_risco ==
foco_na_primeira_entrega){
throw new
Exception(“FALHA”);
}else{
return “SUCESSO!!! :)”;
}

22. {
“Produtividade”:
“Seu time é ágil?”,
}

23. - Preciso ser ágil!
• Requisitos
• Planejamento
• BluePrint
• Documentação
• RoadMap
• Deploy
• Monitoramento
• Controlde de
Incidentes

24. { Modelo V / Desenvolvimento Ágil}
T=> Time + Cultura + Pessoas + Comunicação + Compromisso
T=> Tecnologia + Documentação + Investimento + Foco no Cliente

25. { Domain Driven Design }
Projeto Orientado a Domínio
“Atacando as complexidades no coração do software”
(Eric Evans)

26. [ Objetivos]
• Alinhamento as regras de negócio
• Favorecer reutilização de código
• Mínimo de acoplamento
• Independência de Tecnologia

27. [ 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>

28. { Pilares da Orientação a
Objeto }
• Herança
• Polimorfísmo
• Encapsulamento
• Abstração

29. { 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

30. [ Modelo Conceitual ]
A modularidade se
torna mais crítica a
medida que do
design cresce e se
torna mais complexo.

31. [Modelo
Conceitual]

32. [ Isolando o Domínio ]
Cada conceito do modelo de
domínio deve refletir um
elemento da implementação.

33. { 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

34. { SOLID }
/*
São cinco princípios básicos da orientação a objeto
*/

35. { Single Responsibility }
< Principio da Responsabilidade Única />
Uma classe deve ter um, e somente um, motivo para mudar

36. { 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 }

37. { Open-Closed }
< Princípio Aberto-Fechado />
Você deve ser capaz de estender um comportamento de uma classe,
sem modificá-lo.

38. { 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;
}
}

39. { Liskov Substitution }
< Princípio da Substituição de Liskov />
As classes derivadas devem ser substituíveis
por suas classes base.

40. { 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();
}
}

41. { Interface Segregation }
< Princípio da Segregação da Interface />
Muitas interfaces específicas são melhores
do que uma interface única.

42. { Dependency Inversion }
< Princípio da inversão da dependência />
Dependa de uma abstração
e não de uma implementação.

43. { 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();
}
}
worker = w;
}
public void manage() {
worker.work();
}
}

44. { Dependency Inversion }
Containers de injeção de dependência:
Exemplos: Microsoft Unity, Ninject, Spring, Spring.net, etc...
Uso:
1) Registro da interface e tipo
2) Resolve e carrega o tipo registrado para a interface ou identificador

45. { 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

46. { ! }

47. {
Seja hoje um pessoa
melhor do que
você foi ontem
}

48. Pesquise...

49. Pesquise...
Estude...

50. Pesquise...
Estude...
Domine...

51. Pesquise...
Estude...
Influencie...
Domine...

52. Obrigado :)

53. Perguntas?

54. Obrigado :)
E-mail: abrandao@mundipagg.com
Skype: abrandao@mundipagg.com
Twitter: @abrandaolustosa
LinkedIn: abrandaol