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.
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.
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
8.
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.” */
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
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
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