avant-propos
Près de deux ans, j'ai été une entreprise à Taiwan pour faire système de recherche et de développement, cela peut être l'expérience de travail récente peut être à sa fin. Cet article peut être pris en compte dans l'examen et réfléchir sur cette expérience.
architecture du système
Voici le point principal de la couche d'accès au service, dans notre architecture actuelle du système et il n'y a pas de couche d'accès au service. Mais je pense à l'avenir, la couche d'accès au service qu'il ya encore très nécessaire.
l'accès au service de couche Effet
- effet de revêtement. Parce que les unités commerciales au sein de l'entreprise pour servir plusieurs secteurs d'activité, le développement quotidien en réponse aux différents besoins d'affaires, nous ajoutons souvent beaucoup de conversion, la logique d'interprétation dans le service sous-jacent, introduit une couche d'accès au service que nous pouvons mettre ce code l'accès à la couche de service.
- isolement d'affaires. Chaque secteur d'activité au sein de l'entreprise a une scène unique de ses activités, et certains appels pour le service est relativement plat, et certaines entreprises peuvent se concentrer sur l'épidémie à un certain moment. Comme la table, nous ne voulons pas une scène ou un bug causé toutes les opérations commerciales ne sont pas disponibles, il est possible pour la couche d'accès pour limiter les services aux entreprises en cours (programme principal est les paramètres de mise au point Sentinal limitant).
- Facile à gérer la capacité de sortie externe. Les développeurs ne doivent écrire et maintenir la documentation de la documentation d'interface pour la couche d'accès d'interface dans le développement ultérieur. En second lieu, le développeur entière à Taiwan tant que la sortie externe de la couche d'accès à comprendre ces capacités peuvent avoir une capacité cognitive dans le tableau d'ensemble, pas face à plusieurs de chaque interface de service sous-jacent.
Faits saillants commerciaux à Taiwan
Dans la station des métiers de la construction, ou une entreprise de conception majeure à Taiwan en fait deux choses:
- Comment fournir la procédure d'accès raisonnable à la disposition du côté commercial. Laissez le côté commercial de la pleine mise en œuvre de leurs activités tout en étant en mesure d'accéder rapidement à
- Comment gérer les différences dans les systèmes d'entreprise de Taiwan pour les différents processus d'affaires sur les entreprises
Processus d'accès
Dans le flux principal d'accès figure:
Dans la première page l'utilisateur d'acheter des biens. Ensuite , appelez le côté commercial de l'interface, de fournir des informations et d' autres services achetés l' interface de la station d'appel du parti pour créer une seule transaction, le numéro de commande de transaction et obtenir eux - mêmes associés à des données d'entreprise, puis evoke composante de paiement universel du numéro de commande de transaction.
composante de paiement Susciter à payer pour ce parti ne se soucient pas de la logique métier, composante de paiement? Interagir directement avec l'accord Taiwan.
Après paiement réussi, les unités logiques de commandes de traitement des transactions, la manipulation du côté des entreprises après le rappel d'achèvement, puis la logique métier côté entreprise basée sur un seul numéro de rappel de traitement des transactions lui - même.
Procédure d'accès dans la conception et l' évolution effectivement rencontré quelques problèmes: d'
abord créé dans la première étape du côté affaires ne sont pas des données de commandes visibles, qui a également causé un grand nombre de systèmes de transaction de données de commandes non valides, et plus tard optimisés pour ordres de Bourse, numéro de commande multiplexe unique numéro de transaction, qui est transparente pour le côté commercial , en fait , aucun effet.
Il y a un rappel côté entreprise de traitement des paiements et de rappel de cette étape, un premier appel synchrone, qui a également provoqué un flux inverse du côté commercial du système dépend de l'état de la commande, lorsque le côté commercial du système échoue, l' état de la commande ne peut pas être normal circulation.
Les différences dans les entreprises
Les deux services à titre d'exemple ci - dessous, je viens de décrire sur les processus, processus d'affaires sur le réel peut être plus complexe.
Lorsque l'élimination des différences dans les affaires, il faut d' abord analyser les différents processus d'affaires, identifier les plus complexes affaires comme échantillon, ce qui est une analyse logique à usage général, qui est la logique il y a une différence.
Des exemples du centre commercial est probablement le plus processus complexe, les membres du processus est plus simple. Selon la figure , nous pouvons persister dans les noeuds de données de commande en deux différence de débit,
pré-traitement avant l'ordre persistant, le post-traitement après l'ordre de persistance.
Nous formons un seul composant pour des fonctions logiques pour tirer loin, et pré-traitement et de post-traitement pour créer différents composants selon l'entreprise de la chaîne d'appel.
Voici un exemple de code:
Nous définissons d' abord le composant
public interface Processor<T, R> {
/**
* 执行内容 ,中断抛出{@link com.xxx.xxx.infrastructure.exception.ProcessorInterruptedException}
*
* @param context
* @param result
*/
void process(T context, R result);
/**
* 触发调用下一个 Processor
*
* @param context
* @param result
*/
void fireNext(T context, R result);
/**
* 检查是否执行该 Processor
*
* @param context
* @param result
* @return
*/
boolean check(T context, R result);
}
public abstract class AbstractProcessor<T, R> implements Processor<T, R> {
private AbstractProcessor<T, R> next = null;
public AbstractProcessor<T, R> getNext() {
return next;
}
@Override
public boolean check(T context, R result) {
return true;
}
public void setNext(AbstractProcessor<T, R> next) {
this.next = next;
}
public void invoke(T context, R result) {
try {
process(context, result);
fireNext(context, result);
} catch (ProcessorInterruptedException ex) {
return;
} catch (Exception ex) {
log.error(ex.getMessage(), ex);
throw ex;
}
}
@Override
public void fireNext(T context, R result) {
if (next != null) {
if (check(context, result)) {
next.invoke(context, result);
} else {
if (next.getNext() != null) {
next.getNext().invoke(context, result);
}
}
}
}
}
Montage de constructions définissent alors la chaîne classe abstraite
public abstract class AbstractProcessorBuilder<T, R> {
@Autowired
protected AutowireCapableBeanFactory autowireCapableBeanFactory;
protected AbstractProcessor<T, R> instance;
@PostConstruct
public void init() {
initProcessor();
}
public abstract void initProcessor();
public AbstractProcessor<T, R> build() {
return instance;
}
public void addLast(AbstractProcessor<T, R> processor) {
if (instance == null) {
instance = autowired(processor);
return;
}
AbstractProcessor<T, R> next = instance;
while (next.getNext() != null) {
next = next.getNext();
}
next.setNext(autowired(processor));
}
protected AbstractProcessor<T, R> autowired(AbstractProcessor<T, R> processor) {
autowireCapableBeanFactory.autowireBean(processor);
return processor;
}
}
entreprise de la chaîne pré-appel au-dessus de deux
@Component
public class StoreSubmitPreProcessorBuilder extends AbstractProcessorBuilder<SubmitOrderContext, ResultDTO<SubmitOrderResult>> {
@Override
public void initProcessor() {
addLast(new CheckSubmitOrderNumProcessor());
addLast(new CheckItemBuyNumLimitProcessor());
addLast(new PaddingAddressProcessor());
addLast(new CheckDeliveryLimitProcessor());
addLast(new QuerySkuProcessor());
addLast(new CheckSkuProcessor());
addLast(new CalPromotionProcessor());
}
}
@Component
public class PrimeSubmitPreProcessorBuilder extends AbstractProcessorBuilder<SubmitOrderContext, ResultDTO<SubmitOrderResult>> {
@Override
public void initProcessor() {
addLast(new QuerySkuProcessor());
addLast(new CheckSkuProcessor());
addLast(new CalPromotionProcessor());
}
}
Simplifier la présentation du code de commande:
getSubmitPreProcessorBuilder(bizType).build().invoke(context, ret);
if (!ret.isOk()) {
return ret;
}
//.....
Grâce à ce volet de la route, nous pouvons obtenir un autre ProcessorBuilder selon différents processus d'affaires pour faire face aux différences.
station de pensée
A Taiwan fournir non seulement l'interface des composants si simple, arrière-plan de gestion tels que le commerce à Taiwan, ont également besoin de fournir l'ordre, la visualisation des données de commande, par la capacité à Taiwan continuer à renforcer, pour rendre le front office de se concentrer davantage sur leurs activités.
la capacité de Taiwan à assurer la promotion en cours, lorsque la demande faite par un seul sens des affaires, comme dans la réalisation de ses histoires de succès peut être généralisé à d'autres entreprises, de sorte que d'autres entreprises bénéficient des dividendes du bâtiment de la station, la seule promotion constante, capacité continue de retour à Taiwan sera plus forte.
Taiwan est non seulement dans l'architecture d'affaires, mais aussi un cadre organisationnel, seule organisation indépendante pour assurer que les ressources ne sont pas enclins à générer des affaires.
A Taiwan à construire en fonction de la situation réelle des entreprises, une vision claire est prêt à résoudre le problème des entreprises correspondantes.
Conseils: ci-après en se référant également aux entreprises de service exemplaire échantillon Jingdong, le code échantillon est également une modification du code réel