Introdução: Por que o desenvolvimento de software precisa do Responsibility Driven Design (RDD)? Como as responsabilidades devem ser alocadas? Como combinar o modelo de arquitetura no desenvolvimento real? Este artigo apresenta um modelo geral de alocação de tarefas - GRASP, explica em detalhes os princípios de GRASP por meio de exemplos e compartilha dois casos práticos.
O software é complexo por natureza, e a complexidade do próprio software reside não apenas em resolver o domínio do problema, mas também resolver requisitos não funcionais e problemas específicos do domínio de software: segurança, disponibilidade, manutenção, escalabilidade, desempenho, consistência , Tolerância a falhas, estabilidade, reutilização, idempotência, compatibilidade, etc., a tarefa dos desenvolvedores de software é criar a ilusão de "simples". Como organizar um sistema complexo? Decompor coisas complexas em diferentes níveis. Os níveis representam diferentes níveis de abstração. Uma camada é construída sobre a outra. Cada camada protege a camada superior da complexidade interna.
1. Por que usar RDD?
Em RDD, acreditamos que "objetos de software têm responsabilidades". Esta definição está de acordo com a forma como as pessoas trabalham juntas em grupos sociais. O software também é escrito por pessoas. Portanto, um sistema de software projetado de acordo com responsabilidades está de acordo com o comportamento humano e é mais fácil Entenda e gerencie. Na arquitetura de microsserviço, diferentes sistemas são responsáveis por diferentes organizações e pessoas.O sistema é considerado um objeto (pessoa) e a interface fornecida pelo sistema é de responsabilidade do objeto (pessoa).
O núcleo do design orientado por responsabilidade é considerar como atribuir responsabilidades a objetos e é aplicável a software de qualquer tamanho, desde sistemas a objetos. A essência da distribuição de responsabilidades é a divisão do trabalho, e a divisão do trabalho é a principal razão para o aumento da produtividade do trabalho.
- Aumento da proficiência, foco em uma determinada área (reduzir a complexidade).
- Economizando tempo, leva muito tempo para a mesma pessoa alternar entre trabalhos diferentes.
- Máquinas e aplicações inventadas artificialmente (ferramentas em campos específicos).
2. Como atribuir responsabilidades a objetos (elementos)?
A atribuição de responsabilidades deve começar com uma descrição clara das responsabilidades. Para objetos de domínio de software, o modelo de domínio descreve os atributos e associações dos objetos de domínio, os atributos e referências das classes correspondentes, e o modelo de caso de uso contém uma série de atividades de comportamento e métodos das classes correspondentes. O método de criação de modelo de domínio pode referir-se a "UML and Pattern Application", UDD, DDD.
Use o modelo GRASP (Padrões de Software de Atribuição de Responsabilidade Geral) para atribuir responsabilidades. GRASP é um modelo de atribuição de responsabilidade geral. Ele nomeia e descreve alguns princípios básicos de atribuição de responsabilidade. Existem 9 modelos no total (alguns princípios GRASP são baseados em outros princípios e padrões de design. Em resumo, existem centenas de padrões de projeto, mas já é muito difícil lembrar os 23 padrões de projeto GoF, sem mencionar os detalhes de cada padrão, portanto, os padrões de projeto precisam ser classificados de forma eficaz. Descreve a natureza do padrão, além de ajudar a acelerar o aprendizado de padrões de projeto, também é mais eficaz para descobrir problemas em projetos existentes (este é o valor da indução).
Ao falar sobre baixo acoplamento e alta coesão, do que exatamente estamos falando? O problema não é o alto grau de acoplamento e a baixa coesão, mas os efeitos negativos que ele produz. Os efeitos negativos costumam se refletir quando ocorrem mudanças. Esses efeitos negativos afetarão a eficiência, a estabilidade e a sustentabilidade de nosso desenvolvimento. , Escalabilidade, capacidade de reutilização, etc. O núcleo do GRASP é como prevenir a mutação (mudança).
Durante o processo de aprendizagem, descobri que GRASP carece de uma exibição estruturada e de resultados resumidos. Por meio do meu próprio entendimento, eu associo o padrão de design GoF, princípios de design orientado a objetos, princípios de design de arquitetura e GRASP comumente usados no desenvolvimento:
Três modelos de distribuição de responsabilidade GRASP
1 Previne mutação
Este modo é basicamente equivalente ao princípio de ocultação e abertura e fechamento de informações. Como expandir a parte alterada sem modificar a função original? Identificar fatores instáveis é particularmente difícil e também determina se podemos fazer um projeto que atenda aos princípios de abertura e fechamento.
Pergunta: Como projetar objetos, subsistemas e sistemas de forma que mudanças internas ou instabilidades não afetem adversamente outros elementos.
Solução: identifique as mudanças ou instabilidades esperadas e atribua responsabilidades para criar interfaces estáveis além dessas mudanças.
Princípios e padrões relacionados:
- GRASP: indireto, polimorfismo
- GoF: modo de massa
- Outros: interface, encapsulamento de dados
2 Baixo acoplamento, alta coesão
O acoplamento é uma medida da conexão, percepção e dependência entre um elemento e outros elementos. A coesão é uma medida da relevância e concentração das responsabilidades do elemento (aqui, os elementos referem-se a classes, sistemas, subsistemas, etc.), acoplamento A coesão e a coesão olham para os problemas de ângulos diferentes, elas dependem uma da outra e se influenciam (os dois pontos a seguir também podem ser ditos ao contrário):
- A coesão é muito baixa, as funções relacionadas estão espalhadas em diferentes módulos e um acoplamento adicional precisa ser adicionado para agregar essas funções, o que afetará vários módulos quando ocorrerem alterações.
- A coesão é muito alta, as funções irrelevantes são reunidas em um módulo e o grau de acoplamento é alto, o que terá efeitos inesperados quando ocorrerem alterações.
Baixo acoplamento
O acoplamento é uma medida da conexão, percepção e dependência entre um elemento e outros elementos. Os elementos aqui se referem a classes, sistemas, subsistemas e assim por diante.
Pergunta: Como reduzir a dependência, reduzir o impacto das mudanças e melhorar a reutilização?
Solução: atribua responsabilidades para tornar o acoplamento o mais baixo possível. Use este princípio para avaliar alternativas.
Modelos ou princípios relacionados:
- GRASP: Previne mutação
Nota: O acoplamento não pode ser considerado independentemente de outros princípios, como especialistas e alta coesão.
Os sistemas fortemente acoplados têm as seguintes desvantagens durante a fase de desenvolvimento:
- A modificação de um módulo produzirá efeitos de ondulação, e outros módulos precisam ser modificados de acordo (geralmente causado por baixa coesão).
- Devido às dependências entre os módulos, a combinação dos módulos exigirá mais esforço e tempo, com baixa reutilização (geralmente causada por alto acoplamento).
Interpretação: Acoplamento significa que existe uma dependência entre os elementos. Quando falamos em "alto acoplamento", do que estamos falando especificamente? É o impacto negativo da dependência, portanto, o cerne do baixo acoplamento é resolver a dependência ruim. Alto e baixo são uma métrica, não um critério para julgar os resultados do acoplamento. É mais preciso usar "mau acoplamento" e "acoplamento fraco". Existem dois principais efeitos negativos do mau acoplamento:
- A própria relação de dependência é intrincada e difícil de manter e entender, e é fácil de produzir omissões e problemas (este ponto é voltado para as pessoas e sua capacidade de lidar com coisas complexas é limitada).
- Quando é dependente de elementos instáveis, é facilmente afetado por mudanças (geralmente é impossível evitar a não dependência).
Então, como fazê-lo? Avalie primeiro a qualidade da dependência: método de dependência, direção da dependência e vínculo de dependência.
direção:
- Dependência de duas vias (pobre)
-
- Os dois elementos mutuamente dependentes não podem agir de forma independente.O nível de classe na arquitetura do sistema de microsserviço não produz problemas particularmente complexos, mas o módulo ou o nível do sistema é particularmente vulnerável a mudanças.
-
- Exemplo: A <-> B, A chama a interface b de B, a interface b de B depende da interface a de A, se a interface ab precisa ser alterada, como os dois sistemas são liberados? A conta com B para liberar primeiro, e B também conta com A para liberar primeiro.Dois elementos que dependem um do outro não podem agir independentemente.
- Dependência circular (pior)
-
- A dependência cíclica é mais longa do que o elo de dependência bidirecional e o escopo de influência é maior.
- Dependência unilateral (bom)
ligação:
- profundidade
-
- B chama A.getC (). GetD (). GetE (). GetF () para obter F.
- Largura
-
- No processo de alargamento do link, é fácil produzir uma mistura de elementos sem restrição e gerenciamento, e também é fácil produzir dependências bidirecionais e circulares.
o caminho:
- Acoplamento de conteúdo (alto)
-
- Quando um módulo usa diretamente os dados internos de outro módulo ou transfere para outro módulo por meio de uma entrada anormal.
- Acoplamento compartilhado / acoplamento comum (alto)
-
- Refere-se ao acoplamento entre os módulos que interagem por meio de um ambiente de dados comum.
-
- A complexidade do acoplamento público aumenta com o número de módulos de acoplamento.
- Acoplamento de controle (meio)
-
- Refere-se a quando um módulo chama outro módulo, o que é passado é uma variável de controle (como uma chave, um flag, etc.), e o módulo chamado realiza seletivamente uma função no bloco por meio do valor da variável de controle;
- Acoplamento de recurso / acoplamento de marcador (médio)
-
- Refere-se a vários módulos que compartilham uma estrutura de dados complexa, como o nome do nome do array, nome do registro, nome do arquivo, etc. na linguagem de alto nível é a marca, de fato, o endereço dessa estrutura de dados é passado;
- Acoplamento de dados (baixo)
-
- Significa que o módulo compartilha dados passando valores, cada um dos quais são os dados mais básicos, e compartilha apenas esses dados (por exemplo, passando um inteiro para a função que calcula a raiz quadrada).
- Acoplamento indireto (baixo)
-
- Não existe uma relação direta entre os dois módulos, a ligação entre eles é totalmente realizada através do controlo e chamada do módulo principal. O acoplamento é o mais fraco e a independência do módulo é o mais forte.
- Sem acoplamento (não)
-
- O módulo não troca informações com outros módulos.
Resolva dependências ruins:
- Gerenciar dependências complexas
-
- Direção da dependência: use dependência unilateral, remova ou enfraqueça dependência bidirecional, não use dependência circular.
-
- Vínculo dependente: observe o princípio da menor consciência.
-
- Dependência: tente usar acoplamento de dados, menos controle e acoplamento de recursos, controle o escopo do acoplamento comum e não use acoplamento de conteúdo. Se o objeto dependente for instável, use acoplamento indireto para diminuir a rigidez do acoplamento.
- Atribua as responsabilidades certas para reduzir a dependência desnecessária: especialistas, criadores.
- Reduza o impacto de elementos instáveis por meio de outros princípios e modelos: alta coesão, ficção pura, controlador, polimorfismo, indireto e menor consciência.
Alta coesão
A coesão é uma medida da relevância e concentração das responsabilidades do elemento.
Pergunta: Como manter o objeto focado, compreensível, sustentável e capaz de suportar baixo acoplamento?
Solução: atribua responsabilidades de acordo com a relevância para manter alta coesão.
vantagem:
- Os elementos decompostos são mais simples e fáceis de entender e manter.
- A divisão de acordo com a relevância pode melhorar a reutilização.
Princípios e modelos relevantes: princípio de responsabilidade única, separação de interesses, modularidade.
Desvantagens da baixa coesão: classes com baixa coesão fazem muito trabalho irrelevante, ou precisam concluir muito trabalho, tais classes causarão os seguintes problemas:
- Dificíl de entender
- Difícil de reutilizar
- Difícil de manter
- Frequentemente afetado por mudanças
Exemplo: uma mudança afeta de 3 módulos para 1 módulo.
resumo
Manter baixo acoplamento e alta coesão por meio de gerenciamento estruturado.
3 criador
O criador nos orienta na atribuição de responsabilidades relacionadas à criação de objetos. Essa opção é manter baixo acoplamento.
Pergunta: Quem deve ser responsável por criar novas instâncias de uma determinada classe?
Solução: Quando uma das seguintes condições for atendida, atribua a responsabilidade de criar a classe A à classe B (quando mais de uma for atendida, a inclusão ou agregação geralmente é preferida).
- B "contém" ou agrega A.
- B registra A.
- B usa A com freqüência.
- B tem os dados de inicialização de A, que serão passados para A quando ele for criado.
Vantagens: suporta baixo acoplamento, pois o criador e a pessoa criada já possuem uma associação, então este método não aumentará o acoplamento.
Modelos ou princípios relacionados:
- GRASP: baixo acoplamento
- GoF: fábrica de concreto, fábrica abstrata
- Outro: parte inteira
Nota: Contenção (o autor marcou "" aqui, porque a inclusão em uml expressa o relacionamento do caso de uso, e também pode ser usado para ilustrar o relacionamento do objeto), agregação, olhar todo-parte na definição UML; inclusão enfatiza forte dependência (A é B Subconjunto, A pertence a B, B não é o todo sem A), a agregação é fracamente dependente (B é composto de A e A não pertence a B).
exemplo:
- O pedido contém mercadorias (o pedido perde sua integridade sem mercadorias e não tem significado).
- O pedido registra Bens relacionados.
- Dados de inicialização de mercadorias:
-
- Caso 1: Apenas os dados de Mercadorias no pedido são necessários. Neste caso, o Pedido possui os dados de inicialização de Mercadorias.
-
- Caso 2: os dados de mercadorias no pedido estão incompletos. Nesse caso, o pedido tem apenas uma pequena parte dos dados de inicialização de mercadorias e o pedido não pode ser o criador.
4 Especialista em informações (ou especialista)
"Informação" não se refere apenas a dados.
Pergunta: Quais são os princípios básicos para atribuir responsabilidades a objetos?
Solução: Atribua a responsabilidade ao especialista em informação, que possui as informações necessárias para cumprir esta responsabilidade
vantagem:
- Os objetos usam suas próprias informações para concluir tarefas, portanto, o encapsulamento de informações é mantido e, portanto, o acoplamento baixo é suportado (pelo menos sem aumentar o acoplamento).
- O comportamento é distribuído entre as classes que possuem as informações necessárias, de forma que as funções sejam mais concentradas e, portanto, seja suportada uma alta coesão.
Modelos ou princípios relacionados:
- GRASP: baixo acoplamento, alta coesão
Nota: Usado junto com "Separation of Concerns" torna o objeto ainda mais coeso, alcançando alta coesão e reduzindo o acoplamento.
Exemplo: Obtenha o valor total de todos os bens adquiridos, Pedido e Mercadorias estão em uma relação um-para-muitos.
Análise: A própria ordem está associada a Mercadorias e compreende a estrutura das Mercadorias. Na legenda, o cliente obtém mercadorias por meio do pedido e faz uma operação lógica para obter a quantidade total de mercadorias. Essa abordagem cria uma dependência desnecessária e aumenta o número de acoplamentos. A responsabilidade de calcular a quantidade total de mercadorias é mais apropriada para o pedido.
Extensão: Em alguns casos, essa solução não é adequada, geralmente devido a problemas de acoplamento e coesão, como: Quem deve armazenar o objeto A no banco de dados? De acordo com o princípio, cada classe deve ter a capacidade de persistir.
5 ficção pura
Para manter um bom acoplamento e coesão, fabrique objetos que não existem no negócio para assumir responsabilidades.
Pergunta: Quando você não quer violar alta coesão e baixo acoplamento ou outros objetivos, mas as soluções baseadas no modo especialista não são adequadas, quais objetos devem ter essa responsabilidade?
Solução: Atribua um conjunto de responsabilidades de alta coesão às classes feitas artificialmente. Esta classe não representa o conceito do domínio do problema - coisas fictícias para suportar alta coesão, baixo acoplamento e reutilização.
vantagem:
- Suporta alta coesão, porque as responsabilidades são resolvidas em classes refinadas que se concentram em um conjunto muito específico de tarefas relacionadas.
- Maior potencial de reutilização.
Princípios e padrões relacionados:
- GRASP: baixo acoplamento, alta coesão.
- Normalmente, a aceitação é baseada nas responsabilidades atribuídas ao domínio pelo modelo especialista.
- Todos os padrões de design GoF são pura ficção; na verdade, todos os outros padrões de design também são pura ficção.
Exemplo: Calcule a quantidade total de mercadorias. De acordo com o modo especialista, a responsabilidade de calcular a quantidade total de mercadorias também deve ser atribuída ao Pedido. Dessa forma, os produtos relacionados ao peso total, volume total e total XX também serão atribuídos. Neste momento, as responsabilidades do Pedido serão cada vez maiores e podem ser Gere acoplamento adicional e distribua essas responsabilidades por meio de objetos puramente fictícios para obter um design melhor.
As responsabilidades relacionadas ao cálculo da agregação de commodities são assumidas por meio do objeto fictício GoodsItems.
Extensão: muitas vezes é descoberto que classes fictícias como Util, Handler e Service são usadas no código. A desvantagem é que essas classes são geralmente singletons e os compartilham. As responsabilidades dessas classes fictícias aumentarão (2.000 linhas de código para uma classe Util). Criar Somente objetos fictícios mais próximos do negócio podem facilitar a compreensão e o gerenciamento das relações de acoplamento.
6 controlador
Solução: atribua responsabilidades a uma classe que pode representar uma das seguintes opções:
- Representa todo o "sistema", "objeto raiz", equipamento ou subsistemas principais executando o software, são todas variações do controlador de aparência.
- Representa um cenário de caso de uso no qual ocorre um evento do sistema.
Padrões relacionados:
- GRASP: pura ficção
- GoF: Comando, aparência
- Outro: Camada
O núcleo do controlador é fornecer uma entrada unificada para evitar que os clientes acoplem os elementos internos e mantenham bem os limites:
- camadas de API
- Objeto raiz
- interface
7 polimorfismo
Questão: como lidar com a escolha de um determinado tipo? Como criar componentes de software conectáveis?
Solução: quando as escolhas ou comportamentos relacionados variam com os tipos, use operações polimórficas para atribuir responsabilidades aos tipos de comportamento em mudança.
Vantagens: forte escalabilidade sem afetar os clientes.
Princípios e padrões relacionados:
- GRASP: Previne mutação
- GoF: modo de massa
Quando o pedido é reembolsado, você precisa calcular o valor do reembolso do usuário e o valor da dedução do comerciante e usar diretamente a estrutura de dados retornada pelo serviço de computação antes que o novo negócio de varejo entre. Depois que o novo negócio de varejo entra, a estrutura de dados não é unificada e precisa ser adaptada para atingir o polimorfismo O último código é muito extensível.
Na arquitetura de microsserviço, problemas polimórficos mais complexos são geralmente resolvidos adicionando uma camada, como gateway de pagamento e gateway de entrega.
8 Indireto
A maioria dos problemas em ciência da computação pode ser resolvida adicionando uma camada, caso contrário, adicione outra camada. Por sua vez, a maioria dos problemas de desempenho pode ser resolvida removendo uma camada.
Pergunta: Para evitar o acoplamento direto entre duas ou mais coisas, como as responsabilidades devem ser alocadas?
Solução: Atribua responsabilidades ao objeto intermediário para torná-lo um meio entre outras construções ou serviços para evitar o acoplamento direto entre eles.
Vantagens: Obtenha baixo acoplamento entre os componentes.
Princípios e padrões relacionados:
- GRASP: Prevenção de mutação, baixo acoplamento e um grande número de intermediários indiretos são pura ficção
- GoF: modo de massa
Nota: Indireto é geralmente usado para apoiar a prevenção de mutação.
Quatro modelos de arquitetura
Além do princípio de atribuição de responsabilidade, alguns padrões arquitetônicos também são necessários para nos ajudar a melhorar o terreno.
1 arquitetura em camadas
Em um sistema distribuído, o sistema existe de forma independente e pode ser alterado de forma independente sem afetar outros sistemas. No entanto, à medida que a complexidade geral do negócio aumenta, também traz alguns efeitos negativos: porque o todo é decomposto em um grande número de sistemas independentes, com Aumento da complexidade. As dependências entre os sistemas se tornarão intrincadas e complexas. Mudanças em um sistema afetarão outros sistemas. Problemas inesperados também ocorrerão e a eficiência diminuirá. Neste momento, é necessário redesenhar a arquitetura lógica do sistema distribuído para resolver o mau acoplamento e coesão entre os sistemas, melhorando assim a eficiência.
A arquitetura em camadas é uma forma muito prática e comum. TCP / IP, HTTP, sistemas operacionais, etc., todos usam camadas. A essência das camadas é muito simples: separando as preocupações, obtém-se alta coesão; por meio da dependência e rejeição para baixo Dependência cíclica, usando interfaces, para alcançar baixo acoplamento.
A arquitetura em camadas também tem desvantagens: de acordo com a arquitetura em camadas, o consumo de mensagem deve ser na camada de infraestrutura, mas o consumo de mensagem é para executar uma determinada lógica de negócios, então precisa contar com a camada de aplicativo ou de domínio, se for realmente escrito assim, aparecerá Problema de dependência circular. O problema de dependência pode ser resolvido por inversão de dependência.
2 Arquitetura seis (multi) poligonal (arquitetura em anel de cebola)
Arquitetura Hexagonal (Arquitetura Hexagonal), também conhecida como estilo de arquitetura de porta e adaptador, o número específico de "seis" não tem nenhum significado especial, mas significa apenas uma "magnitude", a definição de hexágono é apenas conveniente e mais vívida compreensão.
A arquitetura hexagonal defende uma nova perspectiva de olhar para todo o sistema.Há duas áreas na arquitetura: "área externa" e "área interna". Diferentes clientes da área externa podem enviar entradas (solicitações de rede, scripts cronometrados, consumo de mensagens, etc.), enquanto a área interna é onde se processa a lógica específica.
Cinco casos
Caso 1: Substitua Jpa por Mybatis
@Component
public class CloseOrderService {
@Autowired(required = false)
@Qualifier("rstOrderTransactionManager")
JpaTransactionManager tm;
public void invalid_order(Long orderId, Long userId, Short processGroup)
throws UserException, SystemException, UnknownException {
//其他逻辑。。。省略
// 开启事务
DefaultTransactionDefinition def = new DefaultTransactionDefinition();
TransactionStatus ts = tm.getTransaction(def);
try {
order = orderDAO.get(orderId);
order.setStatusCode(toStatus);
order.setUpdatedAt(new Timestamp(System.currentTimeMillis()));
orderDAO.save(order);
//提交事务
tm.commit(ts);
} catch (Exception e) {
if (!ts.isCompleted()) {
//回滚
tm.rollback(ts);
}
if (e instanceof SatisfiedStateException) {
return;
}
throw e;
}
}
@Transactional(transactionManager = "rstOrderTransactionManager", rollbackFor = Exception.class)
public void invalidOrder(){
}
}
@Component
public interface OrderDAO extends JpaRepository<OrderPO, Long> {
@Query(value = "sql语句", nativeQuery = true)
Long generateGlobalOrderId(@Param("userId") Long userId,
@Param("restaurantId") Long restaurantId,
@Param("seqName") String seqName);
}
Impacto das mudanças: Caso não ocorra nenhum acidente, o uso do Jpa não será alterado, o que significa que está relativamente estável, portanto, no estágio atual, o acoplamento acima é normal e não terá impacto negativo. Mas nos cenários a seguir, teremos uma sensação muito óbvia de alto acoplamento: Todos pensam que Jpa não é fácil de usar, o que devo fazer se quiser substituí-lo por Mybatis? O código usa diretamente OrderDAO herdado de JpaRepository para manipulação de dados. Como Jpa e Mybatis são escritos de forma diferente, você precisa substituir todos os locais onde OrderDAO é usado:
- As classes que chamam OrderDAO (mais de 70 classes) precisam ser substituídas por um novo dao.
- O local onde JpaTransactionManager.getTransaction () é usado precisa ser substituído pelo TransactionManager de MyBatis.
- O local de uso de @Transactional (transactionManager = "rstOrderTransactionManager") precisa ser alterado para gravar blocos de código para confirmação e reversão da transação, o que é conveniente para tons de cinza.
- As posições alteradas acima precisam adicionar interruptores para criar uma escala de cinza.
Conclusão: como a mudança envolve mais de 70 classes e o método de aquisição do gerenciador de transações também precisa ser modificado, o impacto é bastante grande. Não atende ao princípio de "baixo acoplamento" e pode ser redesenhado usando o princípio do "polimorfismo".
Caso 2: Quem deve elaborar o boleto correspondente ao pedido?
Tomemos como exemplo o sistema de transações Ele.me. A responsabilidade atual de criar uma ordem de pagamento é do serviço boss (um serviço de back-end para apps) .A seguir analisemos.
A criação da ordem de pagamento é dividida em dois cenários:
- A criação de pedidos e ordens de pagamento é concluída em uma operação.
- Quando o usuário retorna à página da lista de pedidos e clica em "Ir para pagar", um pedido de pagamento é criado.
Dependência de criação de ordem de pagamento:
- número do pedido
- Valor do pagamento
- Tipos de pagamento
- Um monte de parâmetros atribuídos pelo sistema de pagamento para identificar o negócio
Nota 1: Se você estiver com fome, haverá apenas uma espécie de empresa de entrega de alimentos.O design atual ainda é muito estável e não mudará muito. Portanto, identificar os pontos de mudança pode avaliar melhor se o projeto do sistema atual é razoável, como: Você está com fome será atualizado para uma empresa de serviços de vida local. De acordo com a estratégia da empresa, pode-se ver que não apenas existiremos no negócio de entrega de alimentos no futuro, mas haverá muitos relacionados à vida local. Para negócios de transação, essas empresas terão sua própria camada de apresentação (app, h5, web) e serviços semelhantes a chefes correspondentes. Se houver 10 partes de negócios, você precisa se conectar 10 vezes no cenário de pagamento, e o pedido será feito Só precisa de uma vez (o pagamento como ferramenta já é relativamente estável e não mudará muito).
- Bos é mais caro do que o pedido para identificar a estrutura do pedido.
- Bos é mais caro do que reconhecer o conhecimento do negócio no domínio da transação. É necessário entender o status da transação em profundidade, para que você possa saber qual status pode ser pago (geralmente para solicitar o desenvolvimento do serviço de pedidos), rompendo a fronteira.
Conclusão: O serviço do chefe não deve ser responsável pela criação de ordens de pagamento, e o pedido é o mais adequado.
Link original: https://developer.aliyun.com/article/776148?
Declaração de direitos autorais: O conteúdo deste artigo é fornecido voluntariamente por usuários registrados em nome real do Alibaba Cloud. Os direitos autorais pertencem ao autor original. A comunidade de desenvolvedores do Alibaba Cloud não possui seus direitos autorais e não assume as responsabilidades legais correspondentes. Para regras específicas, consulte o "Contrato de Serviço de Usuário da Comunidade de Desenvolvedores de Nuvem Alibaba" e as "Diretrizes de Proteção de Propriedade Intelectual da Comunidade de Desenvolvedores de Nuvem Alibaba". Se você encontrar suspeita de plágio nesta comunidade, preencha o formulário de reclamação de violação para denunciá-lo. Depois de verificada, esta comunidade excluirá imediatamente o conteúdo suspeito de violação.