
French: 
EXPOSÉ SUR L'ARCHITECTURE DE
CONNECTIVITÉ À TROIS COUCHES
DE MULESOFT
- Bonjour ! Dans cette session Lightboard,
nous allons parler un peu plus de
INSTRUCTEUR TECHNIQUE PRINCIPAL
ET ARCHITECTE D'INTÉGRATION
l'architecture à trois couches
ou la connectivité orientée API,
et de ce que chacune de ces
couches signifie réellement.
Lorsque vous essayez d'adapter
les besoins de votre
application individuelle
à l'intégration de cette
architecture en couches,
vous devez comprendre que si
vous fragmentez ces couches,
c'est dans le but
d'avoir une architecture
cohérente au final.
Si vous avez donc une application client--
l'application client peut
signifier beaucoup de choses :
ça peut être le système
qui fait un appel HTTP,
ça peut être un appel SOAP
ou ça peut être quelque chose
qui déclenche une chute.
Il existe donc toute une
série de moyens différents
pour obtenir une notification
ou un événement d'un système.
Soyez un peu souple

Japanese: 
MuleSoftの3層接続性アーキテクチャーの説明
- こんにちは、このライトボードセッションでは、
3層アーキテクチャーもしくは
API駆動型接続性について
さらに話します。
その層とはいったいどういう意味でしょうか。
さ、自身のアプリケーションを
この多層アーキテクチャーに
統合してみるかを検討する場合は、
これらの階層を解体することで
結局一貫したアーキテクチャーを
作ることを目的とすることを
知っておく必要があります。
だから、クライアントアプリケーションがあれば、
クライアントアプリケーションは色んなことを意味しますから、
HTTP呼び出しを行うシステムだったり、
ソープ呼び出しを行うものだったり、
ファイルの作成をトリガーするものなのかもしれません。
システムから通知またはイベントを取得する
情報がたくさんあります。

Spanish: 
Explicación de la arquitectura
de conectividad de tres capas de MuleSoft.
- Hola, en esta sesión de la pizarra,
vamos a hablar un poco más sobre
la arquitectura de tres capas
o la conectividad de la API.
Y lo que cada una de esas
capas significa realmente.
Ahora, cuando estás
mirando a tratar de calzar
tus necesidades individuales de aplicación
para la integración en
esta arquitectura de capas,
tienes que entender que romper
estas capas,
es con la intención
de tener una arquitectura
coherente al final.
Así que si tienes una aplicación cliente,
una aplicación del cliente
puede significar muchas cosas,
podría ser el sistema que está
haciendo una llamada HTTP,
podría ser hacer una
llamada o podría ser algo
que está provocando una
caída que se está creando.
Así que hay un rango de
diferentes maneras en que
puedes obtener una notificación
o un evento de un sistema.

Portuguese: 
- Oi, nessa sessão
vamos falar um pouco mais sobre
a arquitetura em três camadas
ou conectividade liderada por API.
E o que essas camadas significam.
Quando você tenta encaixar
seu aplicativo individual precisa
integrar-se a essa arquitetura em camadas,
você tem que entender que separar
que as camadas vai...
é a intenção
de ter uma arquitetura coerente no fim.
Então você tem um aplicativo de cliente,
e pode significar várias,
então podem ser o sistema que
está fazendo um chamado HTTP,
pode ser um chamado, ou
pode ser alguma coisa
que provoca uma queda.
Então tem muitas formas diferentes
que pode ter uma notificação
ou evento de sistema.

German: 
Die 3-die dreistufige
Connectivity-Architektur von MuleSoft
- Hi, in dieser Lightboard-Sitzung
werden wir etwas weiter auf
die dreistufige Architektur
oder die API-gesteuerte
Connectivity eingehen.
Wir werden genauer erklären,
was diese Stufen wirklich sind.
Bei der Zusammenfassung Ihrer
Anwendungen mitsamt ihren
individuellen Erfordernissen
für die Integration in diese
gestufte Architektur müssen
Sie sich klar sein, dass die
Auftrennung der bestehenden
Ebenen notwendig ist, um daraus
letztlich eine kohärente
Architektur zu produzieren.
Wenn Sie also eine
Client-Andwendung haben,
die kann natürlich vieles sein,
das könnte ein System sein,
das eine HTTP aufruft,
es könnte einen SOAP-Aufruf
tätigen, oder es könnte
etwas sein, das die Erstellung
einer Datei auslöst.
Es gibt also eine breite
Reichweite von Wegen durch die ein
System eine Benachrichtigung
oder ein Ereignis senden kann.

English: 
(whooshing)
- Hi, in this lightboard session,
we're gonna talk a bit more about
the Three-layered Architecture
or the API led connectivity.
And what each of those
layers really means.
Now, when you're looking
at trying to shoehorn
your individual application needs
for integration into this
layered architecture,
you've gotta understand
that breaking apart
this layers will,
it's for the intention
of having a coherent
architecture at the end.
So if you've got a client application,
now client application
can mean many things,
so it could be the system
that's making an HTTP call,
it could be making a soap
call, or it could be something
that's triggering a fall getting created.
So there's a range of different ways
that you can get a notification
or an event out of a system.

Spanish: 
Sé un poco flexible con lo
que consideras un cliente,
es el autor de la solicitud,
cualquiera que sea esa petición,
podría ser un archivo, un
mensaje, una petición HTTP, etc.
Así que el cliente va a
estar en el nivel superior.
Ahora, es una aplicación.
Así que estos son,
esto es una aplicación.
Y va a haber algún tipo de
sistema involucrado a lo que
los datos deben llegar o desde
donde deber ser solicitados.
Así que es el sistema
descendente en esta situación.
En el fondo, también tenemos aplicaciones,
pero estos son los que están
actuando como servidores de
información o como un sistema
de registro si estás familiarizado
con esa terminología.
Estas dos son aplicaciones.
Puedes encontrar que
tienes la misma aplicación
en la parte superior e inferior.
Creo que esto es algo en lo
que la gente se pone un poco,
loca tratando de llegar a un
diagrama donde puedan tener
la Fuerza de Ventas en la
parte superior o inferior,

Portuguese: 
Então seja um pouco flexível
em relação ao cliete
é a origem da solicitação,
seja ela qual for,
pode ser arquivo, mensagem, solicitação.
O cliente vai ficar no nível mais alto.
É um aplicativo.
Então isso é...
É um aplicativo.
E tem um tipo de sistema envolvido
que dados que precisaram ser solicitados.
Então o sistema está nessa situação.
No fundo, também tem aplicativos,
mas esses são aqueles
que agem como servidores de
informação como registro,
se você está familiarizado
com a terminologia.
Então são aplicativos.
Agora você pode descobrir
que tem o mesmo aplicativo
em cima e embaixo.
Acho que é algo que as pessoas meio que
se viram tentando ter um diagrama
com Vendas em cima e embaixo,

German: 
Sein Sie also flexibel damit,
was sie als Client auffassen.
Es ist der Verursacher der Anfrage,
welche Anfrage das auch immer sein mag,
ob nun eine Datei, Nachricht,
HTTP-Anfrage oder ähnliches.
Dieser Client operiert also
hier auf oberster Ebene.
Der ist also eine Applikation.
Das hier sind also,
das ist eine App.
Und darin ist es eine Form
von System involviert, zu dem
Daten geliefert werden oder
aus dem sie angefragt werden.
In dieser Situation ist
es das Downstream-System.
Hier unten haben wir also
ebenfalls Apps, aber diese
agieren als Informationsserver oder als
Systems of Record; den
Begriff kennen Sie womöglich.
Diese beiden sind also jeweils Apps.
Es kann vorkommen, dass die
selbe App die obige und die
untere Funktion erfüllt.
Das ist wo dann oft vorkommt,
dass sich Leute beim Erklären
in sich selbst verfangen und
versuchen, eine Darstellung
zu erstellen, in der Salesforce
oben und unten gleichzeitig

French: 
avec ce que vous
considérez comme un client,
c'est l'auteur de la requête.
Quelle que soit cette requête,
ça peut être un fichier, un
message, une requête HTTP, etc.,
le client sera mis au plus haut niveau.
C'est une application.
Ceci est--
Ceci est une application
et il y aura une sorte de système concerné
par la réception ou la
requête des données.
C'est le système subséquent
à cette situation.
En bas, nous avons
également des applications,
mais celles-ci
agissent comme des serveurs d'informations
ou comme un système d'enregistrement
si vous connaissez cette terminologie.
Ces deux ci sont des applications.
Vous pouvez constater que
vous avez la même application
en haut et en bas.
Je pense que c'est une
chose qui fait un peu
tourner en rond les gens qui essaient
d'aboutir à un diagramme
intégrant Salesforce en haut ou en bas,

Japanese: 
何をクライアントとするかについて柔軟性を持つようになって下さい。
クライアントがリクエストの発行者です。
そのリクエストには、
ファイルやメッセージ、HTTPリクエストなどがあります。
では、クライアントは一番上のレベルにあります。
今は、アプリケーションです。
では、これらは...
これはアプリです。
そして、データの送信先かリクエスト元となる
何らかのシステムがあります。
この状況では、それが下流システムとなります。
下には、アプリがありますけど、
これらは情報のサーバーか
システム・オブ・レコードとなります。
後者の用語をご存知かどうかが分かりませんけど。
では、両方はアプリです。
では、上下には同じアプリが
ある場合もあります。
セールスフォースを上か下に置いたり
あっちこっちで線を引いたり
図面の作成に悩んでいる

English: 
So be a bit flexible with
What you regard as a client,
it is the originator of the request,
whatever that request is,
it could be a file, message,
HTTP request, and so on.
So the client is gonna be
sitting up at the top level.
Now, it's an application.
So these are,
this is an app.
And there's going to be
some sort of system involved
that data needs to get
to or be requested from.
So it's the downstream
system in this situation.
Down the bottom, we also have apps,
but these are ones that are
acting as servers of information
or as a system of record
if you are familiar with that terminology.
So these are both apps.
Now you may find that
you have the same app
at the top and the bottom.
I think this is something
where people get a bit,
twisting themselves up trying
to come up with a diagram
where they have Salesforce
at the top or at the bottom,

Spanish: 
y tratando de dibujar
líneas por todo el lugar.
Mi recomendación es separar
la interacción con el cliente
y la interacción con el servidor.
Así si estás sirviendo una petición,
te pones a ti mismo en el fondo,
la misma aplicación podría
y probablemente debería
aparecer en la parte superior
en la parte inferior.
Así que hablemos de la capa superior,
que es la capa de experiencia.
Pueden verlo como una API.
Pero mi recomendación es que
a veces el término API
tiene una suposición
con la persona con la que estás hablando.
El API podría significar
un tipo de descanso JSON.
Y mucho de lo que vas a hacer
en esta capa de experiencia
no va a estar relacionado con los API.
Así que para ir un poco más
profundo en el tipo de cosas
que podría estar aquí.
Algunos serán API's.
Por supuesto que sí.
Pero otros otros tipos de aplicaciones
que estarás construyendo
aquí están arrastrando

Japanese: 
人が多いと思います。
だから、クライアント操作と
サーバー操作を分けることをお勧めします。
リクエストをサーブする場合は、
自身を下に置きます。
同じアプリケーションは
上下に表示した方がいいでしょう。
では、体験層である
一番上の階層について話しましょう。
では、これはAPIとして考えられます。
私のお勧めについて、
APIという言葉は、話し相手が
何かを仮定する場合があります。
そういう人にとってはAPIとはRESTfulなJSON式サービスを意味するかもしれません。
そして、この体験層での
活動の大部分は
APIに関係ありません。
では、そこにあるものについて
さらに深く調べましょう。
一部がAPIとなります。
確かに。
でも、ここで構築する
アプリケーションの中には、

Portuguese: 
e tentando desenhar linhas em toda parte,
Recomendo separar a interação de cliente
e a do servidor.
Se está cumprindo uma solicitação,
se coloca no fundo,
a mesma aplicação pode
e provavelmente deve
aparecer em cima e embaixo.
Vamos falar da camada superior,
que é a camada de experiência.
Pensa como uma API.
Mas minha recomendação é que
às vezes que o termo API tem a presunção
com a pessoa com quem estão falando.
API pode significar um serviço tipo JSON.
E muito do que está fazendo
nessa camada de experiência
não está relacionado a API.
Então vai ser uma coisa mais profunda
do que temos aqui.
Vão ser alguns API.
Com certeza.
Mas outros tipos de aplicativo
que está construindo aqui

French: 
et en essayant de tracer
des lignes partout.
Je vous conseille donc de
séparer l'interaction client
de l'interaction serveur.
Si vous envoyez une requête,
placez-vous en bas,
la même application pourrait
et devrait probablement
apparaître en haut dans
la partie inférieure.
Parlons de la couche supérieure,
qui est la couche d'expérience.
Vous pouvez la considérer comme une API,
mais je vous conseille
d'avancer des fois le terme API
selon la personne à qui vous parlez.
API peut être, pour elle, un
service de type RESTful JSON,
et une grande partie de
ce que vous allez faire
dans cette couche d'expérience
ne sera pas liée aux API.
Il faut donc approfondir un
peu plus le type de choses
qui peuvent se trouver ici.
Ce sera-- Certaines seront des API,
assurément.
Néanmoins, d'autres types d'applications
que vous développez ici interrogent

German: 
vorkommt und dafür alles
voll mit Pfeilen machen.
Meine Empfehlung ist also,
teilen Sie Client-Interaktion
und Serverinteraktion voneinander auf.
Wenn Sie also eine Anfrage aussenden,
stellen Sie sich nach hier unten.
Die selbe Anwendung kann und sollte wohl
oben und unten auftauchen.
Reden wir also über die obere Ebene.
Das ist die Experience-Ebene.
Sie können dabei
überwiegend an APIs denken,
aber ich würde dazu darauf hinweisen, dass
die Bezeichnung "API" oft mit
einer unpassenden Assoziation
bei Ihrem Gesprächspartner einhergeht.
Er könnte unter "API" einen
RESTful JSON-Service verstehen.
Viel von Ihrer Arbeit in
dieser Experience-Ebene
ist aber nicht verbunden mit APIs.
Um also etwas tiefer in
die Dinge, die sich hier
finden würden, einzutauchen:
Ein Teil davon wird auf
jeden Fall APIs sein.
Absolut.
Aber es sind auch andere
Arten von Anwendungen, die Sie

English: 
and trying to draw lines
all over the place.
So my recommendation is split
apart the client interaction
and the server interaction.
So if you're serving up a request,
put yourself down the bottom,
the same application
could and probably should
appear at the top in the bottom.
So let's talk about the top layer,
which is the experience layer.
Now, you can think of it as an API.
But my recommendation is that
sometimes the term API has a an assumption
with the person that you're talking to.
API might mean for them a
restful JSON type service.
And a lot of what you're gonna be doing
in this experience layer
is not going to be related to API's.
So going a bit deeper
dive on the sort of things
that might be in here.
It will be, some will be API's.
Absolutely.
But others other types of applications
that you're building here are polling

German: 
hier aufbauen, die Umfragen
oder geplante Aufgaben
durchführen, um Werte aus
Datenbanken abzurufen.
Sie werden also nicht unbedingt
dem entsprechen, was sie
als die gängige Vorstellung
von APIs verstehen.
Es gibt durchaus ein Interface.
Also technisch gesehen, ja,
in der Praxis wird der
Begriff aber Leute verwirren.
Wenn wir also all die
Erfordernisse des Client bedenken,
sind die, was die
Experience-Ebene ausmacht.
Es ist die Client-Experience.
Sagen wir in diesem Fall,
die App verwendet HTTP.
Wenn davon hier ein Aufruf
gemacht wird, mit HTTP,
könnte dabei eine Form von
RESTful-API verfügbar werden,
oder eine Form von RPC,
das ist wirklich nicht wichtig.
Was auch immer für den Auftrag
des Client gebraucht wird.
Auf der Experience-Ebene
brauchen Sie also eine Form von
Integrationsanwendung,
die den Client versteht
und die Anfrage entpacken
kann, um etwas durchzuführen.
In diesem Fall hat es etwas
mit dem Client selbst zu tun.

Japanese: 
ポーリングか何らかのスケジュールタスクを実行して
データベースから値を取得するアプリケーションもありますから、
必ずしもここまで分かってきたAPIの意味に
ちゃんと合うわけではありません。
まだインターフェースがありますから、
厳密に言うと、
そうだけれども、
実際は困惑する人がいるかもしれません。
クライアントのニーズを考えると、
それは体験に関わります。
クライアントの体験です。
この場合は、このアプリが
HTTPを採用するとしましょう。
HTTPを用いて呼び出すなら、
暴露するのはRESTfulなAPIだったり
RPCなものなのかもしれません。
どうでもいいです。
クライアントとの作業を行うために必要ならばということです。
それでは、体験レベルでは、
クライアントを理解し、
リクエストを展開できる
何らかの統合アプリケーションが必要です。
だから、この場合は、
クライアントに関わります。

English: 
or running on some sort
of scheduled tasks to go
and retrieve values out of a database.
So they're not necessarily
going to fit nicely
into what you may have come
to understand API to mean,
there's still an interface.
So technically,
yes,
practically, people might be confused.
So if we think about whatever
the needs are of the client,
that's what the experience part is.
It's the client experience.
In this case, let's say this app
is going to be using, say, HTTP.
If they're making a call
through here, using HTTP,
now, this could be a restful
type API that you're exposing,
it could be an RPC style of thing.
It really doesn't matter.
It's whatever's needed to get
the job done with the client.
Okay, so at the experience level,
you need some sort of
integration application
that understands that client
and can unpack the request
to do something more.
So in this case,
it will have something
to do with the client.

French: 
ou exécutent des sortes
de tâches planifiées
pour récupérer des valeurs
dans une base de données.
Elles ne vont donc pas forcément
correspondre parfaitement
à ce que vous assimilez à une API.
Il y a toujours une interface,
donc techniquement,
oui,
en pratique, ça peut prêter à confusion.
Si nous pensons donc à
tous les besoins client,
c'est de ça qu'il s'agit
dans la partie expérience.
C'est l'expérience client.
Dans le cas présent, disons
que cette application
va par exemple utiliser HTTP.
Si elle fait un appel par
ici, en utilisant http,
cela pourrait être une API de
type RESTful que vous exposez,
cela pourrait être une forme de RPC,
cela n'aura pas vraiment d'importance.
C'est tout ce qu'il faut
pour que le travail soit fait côté client.
Bon, au niveau donc de l'expérience,
il vous faut une sorte
d'application d'intégration
qui comprend ce client
et qui peut déployer la
requête pour en faire plus.
Dans le cas présent,
cela sera donc lié au client.

Portuguese: 
contando com tarefas programadas
e recuperar valores de base de dados.
Então não precisa encaixar bem
no que você entende como API,
ainda tem uma interface.
Então tecnicamente,
sim,
praticamente, as pessoas podem confundir.
Então pensamos as
necessidades dos clientes,
é a parte da experiência.
É a experiência do cliente.
Nesse caso, vamos dizer
que esse aplicatico
vai usar, digamos, HTTP.
Se fizer um chamado por aqui usando HTTP,
pode ser o tipo de API que esá exposto,
pode ser um estilo RPC.
Não importa.
É o que precisa para atender o cliente.
Em nível de experiência,
você precisa de um app de integração
que entenda aquele cliente
e faça algo além do solicitado.
Nesse caso,
vai ter algo a ver com o cliente.

Spanish: 
o corriendo en algún tipo
de tareas programadas
para recuperar los valores
de una base de datos.
Así que no necesariamente
van a encajar bien en lo que
puede que entiendas que significa el API,
todavía hay una interfaz.
Así que técnicamente,
Sí,
prácticamente, la gente
podría estar confundida.
Si pensamos en cualquiera de
las necesidades del cliente,
eso es lo que la parte
de la experiencia es.
Es la experiencia del cliente.
En este caso, digamos que esta aplicación
va a usar, digamos, HTTP.
Si están haciendo una llamada
a través de aquí, usando HTTP,
esto podría ser un tipo de API de descanso
que estás exponiendo, podría
ser algo del estilo de la RPC.
Realmente no importa.
Es lo que sea necesario para
hacer el trabajo del cliente.
Así que a nivel de experiencia,
necesitas algún tipo de
aplicación de integración
que entienda a ese cliente
y pueda solicitar la
petición de hacer algo más.
Así que en este caso,
tendrá algo que ver con el cliente.

German: 
Wenn das hier also
Client X ist, dann ist das hier die
Client-X-Experience-Anwendung,
also Integrationsanwendung.
Nehmen wir uns ein anderes
Beispiel für einen Client.
Das könnte etwas sein wie,
wenn wir eine App haben:
Die hier nennen wir App Y.
Und diese erstellt eine Datei
in irgendeinem Pfad.
Und in dem Bereich ist es
unkonventionell, es API zu nennen.
Ja, es ist eines.
Das API wird von der Erstellung
einer Datei verwendet,
aber das ist für manche Leute
vielleicht nicht so schlüssig.
Wenn Sie Ihre Mule-Anwendung
erstellen, um diese
spezifische Client-Experience
zu handhaben,
verwendet sie wahrscheinlich
sowas wie einen Auftragsplaner.
Das ist also eine
Auftragsplanungs-Anwendung.
Die läuft in zyklischer Frequenz,
um eine Datei wahrzunehmen
und dann etwas damit zu tun.

English: 
So if this is
client X, this will be the
client X experience application
integration application.
So let's look at another
example of a client.
And this would be something
like, maybe we've got a,
an app.
So we'll call this one app Y.
And maybe this one
creates a file sitting
on a directory somewhere.
So this is the part where
I think calling it an API.
Yeah, it is.
The API is triggered by
a file getting produced,
but perhaps not as understandable
for a lot of people.
Now, when you're building
your mule application
to deal with this particular
client experience,
it's going to be using
maybe a scheduler.
So it's gonna be a scheduler
type of application.
So it's gonna be running
on a periodic frequency
to pick up a file and
then do something with it.

Spanish: 
Así que si esto es
cliente X,
esta será la aplicación de
la experiencia del cliente X
aplicación de integración.
Así que veamos otro ejemplo de un cliente.
Y esto sería algo como, tal vez tenemos
una aplicación.
La llamaremos aplicación Y.
Y tal vez esta crea un archivo
que se encuentra en un
directorio en algún lugar.
Esta es la parte en la
que creo que llamarlo API.
Sí, lo es.
La API se activa cuando
se produce un archivo,
pero quizás no tan
comprensible para mucha gente.
Ahora, cuando estás construyendo
tu solicitud de mula
para tratar con esta experiencia
particular del cliente,
va a estar usando
tal vez un programador.
Así que va a ser una aplicación
del tipo programador.
Se ejecutará con una frecuencia periódica

French: 
Ça, c'est donc
le client X.
Ça sera l'application
d'expérience du client X,
l'application d'intégration.
Prenons un autre exemple de client.
CE serrait quelque chose
comme une application--
nous appellerons donc
celle-ci l'application Y,
et elle pourrait
créer un fichier mis dans
un répertoire quelque part.
C'est à ce niveau qu'on
peut l'appeler une API.
Oui, c'est ça.
L'API est déclenchée par
la création d'un fichier,
mais ce n'est peut-être pas
aussi évident pour beaucoup.
Quand vous développez
votre application Mule
pour gérer cette expérience
client particulière,
elle se servira peut-être
d'un planificateur.
Ce sera donc une application
de type planificateur.
Elle s'exécutera régulièrement
pour récupérer un fichier
et en faire quelque chose.

Portuguese: 
Se isso é
o cliente X, o aplicativo de experiência,
a aplicação de integração.
Outro exemplo de cliente.
E pode ser alguma coisa,
talvez a gente tenha
um aplicativo.
Então vamos chamar de aplicativo Y.
E talvez esse
crie um arquivo em algum diretório.
Essa é a parte em que penso em API
É, é sim.
O API é ativado por um arquivo produzido,
mas talvez não compreendido
por muita gente.
Quando está construindo o aplicativo
para lidar com essa
experiência em particular,
talvez possa usar
um agendamento.
Um aplicativo para agendar.
Vai ter uma frequência periódica
para escolher um arquivo e fazer algo.

Japanese: 
これがクライアントXならば、
これがクライアントXの体験アプリケーション、
統合アプリケーションとなります。
では、クライアントのもう一例を見てみましょう。
これはアプリみたいなもの
なのかもしれません。
では、これをアプリYと呼びましょう。
これはどこかのディレクトリでファイルを
作成するやつかもしれません。
では、これをAPIと呼んだら...
まあ、そうだね。
APIはファイルの作成によってトリガーされますけど、
多くの人にとって分かりにくいかもしれません。
では、このクライアント体験に対応する
Muleアプリケーションを構築する際は
スケジューラを使用する
かもしれません。
では、スケジューラタイプのアプリケーションとなります。
ファイルを定期的に取得して
何かをします。

Japanese: 
それでも、クライアント体験です。
まだ所在すべき場所に属しています。
別のクライアント体験とはあまり違いません。
では、さらに例として、
メッセージングキューに入っていくものがあるかもしれません。
メッセージングキューだったりトピック、
何らかのアプリがあれば、
メッセージをキューに置きます。
で、キューに入っているものを取得して
何かをするものを必要とします。
また、別のクライアント体験を
必要としますけど、
これはJMSを待機するかもしれません。
それを取り上げてすぐに
エコシステムに適用できます。
体験レベルに属するものの
例はこちらです。
APIみたいなものに見えないかもしれませんけど、
残りの環境のインターフェースとなります。

Spanish: 
para recoger un archivo y
luego hacer algo con él.
Sigue siendo la experiencia del cliente,
todavía pertenece a un lugar,
necesita un lugar para vivir.
Así que es un tipo de experiencia
de cliente muy diferente.
Ahora, otros ejemplos,
puede que tengas algo que
vaya a la cola de mensajes.
Así que si tienes una cola de mensajes
o un tema, algún otro tipo de aplicación.
Y pone los mensajes en una cola,
y necesitas algo para
recuperar las cosas de la cola
y hacer algo con él.
Así que de nuevo, todavía
necesitas un tipo diferente
de experiencia del cliente.
Pero este podría estar
escuchando a un JMS.
Recoge eso y luego está listo para ir
al resto de tu ecosistema.
Hay algunos ejemplos
de cosas que pertenecen
en la capa de experiencia.
Puede que no se sientan
como si fueran API,
pero son la interfaz con
el resto de tu paisaje.

Portuguese: 
Ainda é a experiência do cliente,
ainda pertence a algum lugar.
Não é uma experiência muito diferente.
Outros exemplos,
pode ter algo que vá
para a fila de mensagens.
Se você tem uma fila de mensagens
ou de tópicos, um tipo de aplicativo.
Se coloca mensagens em uma fila,
e precisa de algo para recuperar a fila
e fazer algo com ela.
Então você ainda precisa
de um tipo diferente
de experiência de cliente.
Mas esse pode ser ouvir um JMS.
Escolhe isso e está pronto pra ir
para o resto do ecossistema.
Então tem exemplos de coisas
na camada de experiência.
Podem não parecer API,
mas é a interface para
o resto do ambiente.

German: 
Sie gehört also immer noch
zur Client-Experience,
sie gehört immer noch wo
hin, muss wo ablaufen.
Das ist also keine so andere
Art von Client-Experience.
Dann, weitere Beispiele,
Sie haben vielleicht etwas, das zu einer
Messaging-Warteschlange gehört.
Sie haben also eine
Messaging-Warteschlange,
oder ein Topic, eine andere Art von App.
Die speist Messages in eine Warteschlange
und Sie wollen die Inhalte
dieser Warteschlange abrufen,
um sie zu bearbeiten.
Sie brauchen also wieder eine
andere Client-Experience.
Diese empfängt beispielsweise ein JMS.
Es greift die Daten daraus
auf und ist dann bereit,
den Rest Ihrer
Systemumgebung zu bespeisen.
Das sind also ein paar
Beispiele für Dinge, die in die
Experience-Ebene gehören.
Sie muten vielleicht nicht
direkt als APIs an, aber sie
bieten eine Schnittstelle in
den Rest Ihrer Arbeitsumgebung.

French: 
Il s'agit toujours de l'expérience client.
Ça se rapporte toujours à un endroit.
Il lui faut un endroit pour vivre.
Ce n'est pas un type d'expérience
client trop différente.
D'autres exemples.
Vous pouvez avoir quelque chose qui va
dans une file d'attente de messagerie.
Si vous avez une file
d'attente de messagerie
ou un sujet, une autre
sorte d'application,
et qu'elle mette les
messages en file d'attente,
il vous faut quelque chose pour récupérer
le contenu de la file d'attente
et en faire quelque chose.
Là encore, il faut toujours un autre type
d'expérience client,
mais celle-ci peut être l'écoute d'un JMS.
C'est récupéré et c'est
prêt ensuite à aller
dans le reste de votre écosystème.
Il y a donc des exemples
de choses qui font partie
de la couche expérience.
Elles n'ont peut-être
pas l'air d'être des API,
mais constituent l'interface
de vos autres environnements.

English: 
So it's still the client experience,
it still belongs somewhere
it needs somewhere to live.
So that's not too different
type of client experience.
Now, other examples,
you may have something that
goes into a messaging queue.
So if you've got a messaging queue
or topic, some other sort of app.
And it puts messages into a queue,
and you need something to
retrieve the stuff off the queue
and do something with it.
So again, you still need a different type
of client experience.
But this one might be listening to a JMS.
It picks up that and then it's ready to go
into the rest of your ecosystem.
So there's some examples
of things that belong
in the experience layer.
They may not feel like they're API's,
but they are the interface into
the rest of your landscape.

Spanish: 
Bien, ahora si bajamos al siguiente nivel.
Estamos empezando a hablar sobre
procesos de negocios podríamos decir.
Estos deben tener un mapeo razonablemente
parecido a algo que tu negocio entiende.
Así que si estás tratando
con información de clientes
o tus capacidades de transacción contable,
estas API, estas dos capas
inferiores son críticas
para lograr la reutilización
de tu ecosistema.
Hay algunos principios generales
que estamos tratando de abordar.
No nos repetimos a nosotros mismos,
lo que quiere decir "No te repitas".
Manténlo simple y sucinto.
Así que estos principios impulsan
mucho de lo que vas a hacer
en términos de descomposición
lo que de otra manera sería un gran bulto.
Lo vas a romper en pedazos
para que puedas abordar tu reutilización.
mantener la arquitectura general simple
y obtener una claridad general
del aislamiento entre tus
diferentes clientes y servicios.
Entonces ese aislamiento,

French: 
Bon, maintenant, si nous
passons au niveau suivant,
nous commençons à parler de
processus métier en quelque sorte.
Ils doivent être assez proches
de ce que votre entreprise comprend.
Si vous traitez des informations
sur les clients ou de vos--
vos capacités de transaction comptable,
ces API sont désormais ces
deux couches inférieures
qui sont essentielles pour
réutiliser de votre écosystème.
Nous essayons de répondre à
certains principes généraux :
ne pas se répéter,
c'est-à-dire, Ne Vous Répétez pas,
faites Simple et Succinct.
Ces principes déterminent
une grande partie
de ce que vous allez faire,
s'agissant de décomposer
ce qui serait autrement un gros bloc.
Vous allez le fragmenter
en vue d'une réutilisation.
Faites simple avec
l'architecture dans son ensemble
et clarifiez l'ensemble
de l'isolation entre vos
différents clients et services,
pour que cette isolation,

German: 
Gut, wenn wir jetzt zur
nächsten Stufe hinunterkommen,
reden wir über Unternehmensabläufe,
wenn Sie so wollen.
Die sollten also einer Struktur
ähneln, die für den Aufbau
Ihres Unternehmens verständlich ist.
Wenn Sie sich also mit Ihren
Kundeninformationen befassen,
oder Ihren
Rechnungswesens-Transaktionsmöglichkeiten,
Diese APIs, in diesen
zwei unteren Stufen, sind
essenziell, um Ihr Ökosystem
wiederaufgreifbar zu machen.
Es gibt hier also einige
übergreifende Grundsätze, die wir
in diesem Bereich verwirklichen wollen.
Uns nicht wiederholen, also
Don't Repeat Yourself.
Keep It Simple and Succinct.
Diese Grundsätze bestimmen
einen Großteil der
Verfahrensweisen, mit denen
Sie hier komprimieren werden,
was sonst eine riesige Masse wäre.
Sie zerlegen sie, damit Sie die Teile für
Ihre Wiederverwendung zuordnen können,
die Gesamtarchitektur simpel halten können
und insgesamt Klarheit schaffen können,
über die Abgrenzung
zwischen Client und Service.
Abgrenzung von
Verwendungsebenen für Elemente,

Portuguese: 
Agora ao próximo nível,
estamos começando a falar
de processos de negócios, se quiser.
Pode haver um mapeamento próximo
a algo que seu negócio entenda.
Se está lidando com informação de cliente
nas suas capacidades
de transação da conta,
então esses API, essas
duas camadas de baixo
são críticas para ter
o reuso do ecossistema.
Então são alguns princípios
que tentamos abordar.
Não nos repetir,
que é Don't Repeat Yourself.
Keep It Simple and Succinct.
Esses princípios guiam muito
do que vamos fazer em decomposição,
o que seria um grande obstáculo.
Você vai quebrar
para encaminhar o reuso.
Manter a arquitetura simples
e ter uma clareza total
do isolamento entre cliente e serviço.
Então o isolamento,

Japanese: 
では、次のレベルに下がると、
ビジネスプロセスについての
話となります。
貴社が把握しているものとの
マッピング性が割と高い必要があります。
顧客情報や
会計取引ケーパビリティを取り扱う場合は、
これらのAPI、これら下2層は
エコシステムの再使用に不可欠です。
では、包括的な原則を
取り扱おうとしています。
自分を繰り返さないこと。
簡単で簡潔なままにすること。
これらの原則は
解体しなければ大きな塊になって
しまうものを解体します。
再使用に取り組むために
解体します。
全体的なアーキテクチャーを簡単なままにして
クライアントとサービスの隔離を
明らかにします。
では、その隔離について、

English: 
Okay, now if we go down to the next level,
We are starting to talk about,
business processes if you like.
These should have a
reasonably close mapping to
something that your business understand.
So if you're dealing with
customer information or your,
your accounting transaction capabilities,
so these API's now these bottom two layers
are critical to getting the
reuse out of your ecosystem.
So there's some overarching principles
that we're trying to address.
Not repeating ourselves,
which is Don't Repeat Yourself.
Keep It Simple and Succinct.
So these principles drive a lot
of what you're going to be
doing in terms of decomposing
what would otherwise be a big lump.
You're gonna break it apart
so that you can address your reuse.
Keep the overall architecture simple
and get an overall clarity
of the insulation between your
different client and service.
Okay, so that insulation,

English: 
its layers to try and
give you flexibility.
Alright, now let's go and
talk about this process layer.
Now these ones,
I would say,
picking a restful JSON type approach
makes a lot of sense to me.
Because over the years,
I've learned that XML
although it used to have
a lot better tooling has
the fundamental flaw that
if you add an extra field that comes back
to someone who's using a schema,
by default you'll find that
schemas are a bit inflexible.
So adding an extra
field breaks everything.
So if you want flexibility
in your bottom two layers,
settling on a format that
can accommodate change,
and the most common change I've seen
is adding extra fields coming back.
Yes, there's adding new functionality.
That's not a breaking change
on various approaches.
But I think when you've
got a data structure
that's coming back and you
add an extra couple of fields,
you don't want every existing
consumer having to go
and make code changes to accommodate that.
They should just ignore those fields.

French: 
ses couches, essayent de vous
apporter de la flexibilité.
Très bien. Parlons maintenant
de cette couche de processus.
Celles-ci--
Je dirais que
le choix d'une approche
de type RESTful JSON
me semble très judicieux,
parce qu'au cours des années de--
J'ai appris que le XML,
bien qu'il ait été bien
mieux outillé par le passé,
a un défaut fondamental selon lequel
si vous ajoutez un autre champ qui renvoie
à quelqu'un qui utilise un schéma,
par défaut, vous constaterez que
les schémas sont un peu rigides.
L'ajout d'un autre champ interrompt tout.
Alors, si vous voulez de la souplesse
dans vos deux couches inférieures,
choisissez un format qui
peut s'adapter au changement,
et le changement le
plus courant que j'ai vu
est l'ajout d'autres champs de renvoi.
Oui, il y a l'ajout de
nouvelles fonctionnalités.
Ce n'est pas un changement
radical dans diverses approches.
Je pense que lorsque vous
avez une structure de données
qui renvoie et que vous
ajoutez d'autres champs,
il ne faut pas que chaque
consommateur actuel ait à aller
modifier le code pour s'en accommoder.
Il devrait simplement ignorer ces champs,

Spanish: 
son capas para tratar
de darte flexibilidad.
Muy bien, ahora vamos a hablar
de esta capa de proceso.
Estas,
yo diría que,
eligen un enfoque relajado tipo JSON
tiene mucho sentido para mí.
Porque a lo largo de los años,
he aprendido que el
XML, aunque solía tener
una herramienta mucho mejor
tiene el defecto fundamental
de que si añades un campo extra que vuelve
a alguien que está usando
un esquema, por defecto,
encontrarás que los esquemas
son un poco inflexibles.
Así que añadir un campo
extra lo rompe todo.
Así que si quieres flexibilidad
en las dos capas inferiores,
establece un formato que pueda
acomodarse a los cambios,
y el cambio más común que he visto
es agregar campos
adicionales que regresan.
Sí, se está añadiendo
una nueva funcionalidad.
Eso no es un cambio
radical en varios enfoques.
Pero creo que cuando tienes
una estructura de datos
que regresa y añades
un par de campos extra,
no quieres que cada
consumidor existente vaya
y haga cambios en el
código para acomodar eso.
Deberían ignorar esos campos.

German: 
um Ihnen Flexibilität zu gewähren.
Kommen wir nun also zu
dieser Prozess-Stufe.
Für diese, würde ich sagen,
macht die Form einer RESTful JSON-Lösung
am meisten Sinn.
Denn über die Jahre ist mir klar geworden,
dass XML, obwohl es deutlich
besseres Tooling bietet,
die fundamentale Schwäche
hat, dass wenn Sie ein Feld
hinzufügen, das jemandem gesendet wird,
der ein Schema verwendet,
diese Schemata dafür grundsätzlich
recht unflexibel sind.
Das zusätzliche Feld macht
also alles fehlerhaft.
Wenn Sie Flexibilität in den
unteren zwei Stufen wollen,
brauchen Sie ein für Veränderungen
empfängliches Format.
Und die üblichsten Veränderungen,
die ich aus diesem Kontext
kenne, sind nachgefügte
zusätzliche Felder.
Ja, es kommt auch das Hinzufügen
neuer Funktionalität vor.
Das lässt sich in diversen
Ansätzen fehlerfrei umsetzen.
Aber ich denke, wenn eine
Datenstruktur zurück kommt und
Sie einige zusätzliche Felder hinzufügen,
sollte das immer problemlos
funktionieren, ohne dass jeder
bestehende Konsument
Codeanpassungen anwenden muss.
Diese Felder sollten von ihnen
einfach ignoriert werden.

Portuguese: 
as camadas tentam dar flexibilidade.
Tudo bem, agora vamos falar dessa camada.
Agora essas,
eu diria,
escolhendo uma abordagem JSON
faz muito sentido.
Com os anos,
aprendi que o XML, apesar de ter
ferramentas melhores, tem uma falha que,
se colocar um campo extra
para alguém que usa um esquema
por default, vai ser que são inflexíveis.
Então um campo extra quebra tudo.
Se quer flexibilidade
nas duas camadas extras,
em um formato que acomoda mudanças,
e a mais comum que eu vi
foi colocar campos extras.
Sim, e há novas funcionalidades.
Não há mudanças em muitas abordagens.
Mas eu penso que quando se
tem uma estrutura de dados
que volta e você adiciona campos,
não quer que todo consumidor tenha
que fazer mudanças para acomodar.
Devem ignorar esses campos.

Japanese: 
柔軟性を与えてみるための階層です。
それでは、このプロセス層について話していきましょう。
これらは、
RESTfulなJSONタイプのアプローチを
目指すと言えます。
それはとても分かりやすいです。
数年にわたって、
XMLにかつて素晴らしいツールがあったけど、
根本的な欠陥は、スキーマを使用する者に
戻るフィールドを追加したら、
デフォルトではスキーマにちょっと
柔軟性がないことが私は分かってきました。
フィールドブレーキを追加したら全部壊してしまいます。
下2層で柔軟性が欲しいなら、
変更に適応できる形式に決めます。
私の経験で最も一般的な変更は
戻ってくるフィールドの追加です。
はい、新機能の追加がありますね。
その変更は様々なアプローチで壊してしまいません。
でも、戻ってくるデータ構造があって
いくつかのフィールドを追加する場合は、
既存の顧客がそれぞれそれに対応するために
コードを変更していくことが好ましくありません。
それらのフィールドを無視した方がいいです。

Spanish: 
Y eso es lo que necesitamos.
En las dos capas inferiores aquí,
porque es para evitar que nos repitamos
al hablar con estos servidores de bajada,
y también envolviendo cualquier
lógica que necesitemos
a nivel de proceso de negocios.
De acuerdo, si vemos los procesos API.
Hablemos de,
digamos, los sustantivos
que podríamos encontrarnos
ésas podrían ser una forma de nombrarlas.
Así que si tienes pedidos o
transacciones de clientes,
pero ten en cuenta que
es improbable que puedas establecerte
en una comprensión unificada
de todas las operaciones
y estructuras de datos
para los sustantivos
que cruzan diferentes
límites organizativos.
Es un poco antipatrón intentar
hacer demasiado amplio
el traer el orden al universo
o traer el orden al caos.
Así que puede que quieras tenerlas
divididas por diferentes dominios.

English: 
And that's what we need.
In the bottom two layers here,
because these are to
avoid repeating ourselves
in talking to these downstream servers,
and also wrapping up
whatever logic we need
at a business process level.
Alright, so if we look at process API's.
Let's talk about,
say, the nouns that we might come across
those could be one way to come
up with the naming for these.
So if you had orders or
transactions customer,
but just be mindful that
it's unlikely that you'll
be able to settle on
one unified understanding
of all the operations
and data structures for nouns
that cross different
organizational boundaries.
Okay, it's a bit of an anti
pattern to try and do too broad.
You know bringing order to the universe
or bringing order to the chaos.
So you may want to, have
these divided by different domains.

Portuguese: 
E é o que precisamos.
Nas duas camadas abaixo
porque são para evitar repetição
ao falar com esses servidores
e usar a lógica necessária
em nível de processo de negócio.
Vamos ver as API de processo.
Vamos falar
sobre nomes que surgem
e podem ser de um jeito ou outro.
Se tem pedidos ou transações,
tenha em mente qie
é improvável que consiga estabelecer
um entendimento único de operações
e estruturas para nomes
que cruzem limites
organizacionais diferentes.
É algo sem padrão e bem amplo.
Trazer ordem ao universo
ou trazer ordem ao caos.
Então pode querer
dividir isso em domínios.

Japanese: 
ここ下2層では、
その方が望ましいです。
これらの下流サーバーと通信する時に
自身を繰り返すことを避けて、
そしてビジネスプロセスレベルで
必要なロジックをまとめる必要があります。
それでは、プロセスAPIを見てみると、
私達が遭遇する
名詞について話しましょう。
それでこれらを名づけることができます。
注文や取引、顧客があれば、
異なる組織の境界を越える名詞の
全ての操作やデータ構造の
一元的な考え方に決める
可能性が低いから、
留意して下さい。
それを試みることはちょっとアンチパターンというか幅広すぎます。
宇宙に秩序をもたらすというか、
混沌に秩序をもたらすみたいですね。
これらを個別のドメインに
分けたいかもしれません。

German: 
Und das ist, was wir in diesen
unteren zwei Ebenen brauchen.
Denn diese sind dazu da,
Redundanz in der Kommunikation
mit den Downstream-Servern zu vermeiden,
sowie die Logik, die wir
im Unternehmensprozesslevel
brauchen abzuschließen.
Also gut, um uns die Details
aus der Kategorie der
Prozess-APIs anzusehen, gehen
wir die Schlagwörter durch,
denen Sie in dem Bereich begegnen könnten.
Die sind ein guter Ansatz für
die Namenskonventionen hier.
Also zum Beispiel Bestellungen
oder Transkationen, Kunden.
Sein Sie sich nur bewusst,
dass Sie wahrscheinlich keinen
einheitlichen Konsens
über die Kategorien aller
Operationen und Datenstrukturen
zu Begriffen jenseits der
Fachbereiche im Unternehmen
vorfinden werden.
Es ist ein verhängnisvoller
Anti-Pattern, zu versuchen, eine
zu breit gegriffene, sie
wisssen schon, Gesamtordnung für
das Universum, definieren zu
wollen, um das Chaos zu ordnen.
Sie sollten diese also
wahrscheinlich auf unterschiedliche
Fachbereiche aufteilen.

French: 
et c'est ce qu'il nous faut,
dans les deux couches inférieures ici,
puisqu'il faut éviter de se répéter,
parlant de ces serveurs subséquents,
et aussi de se prononcer
sur toute logique nécessaire
au niveau du processus métier.
Très bien. Si on considère
les API de processus,
on va dire par exemple,
de noms que nous pourrions trouver,
celles-ci pourraient être un
moyen de proposer des noms,
si vous avez des commandes ou
des transactions de client.
Néanmoins, n'oubliez pas
qu'il est peu probable
que l'on puisse déterminer
une compréhension unifiée
de toutes les opérations
et structures de données
des noms qui traversent
différentes frontières organisationnelles.
C'est un peu un anti-modèle
d'essayer de trop généraliser,
de faire régner l'ordre dans
l'univers ou dans le chaos.
Vous pouvez vouloir les
ramifier en différents domaines.

Spanish: 
Si tienes diferentes
departamentos o diferentes silos
que han surgido en tu organización.
Lo más probable es que
esos silos organizativos
están ahí por una razón.
Porque hablan un idioma diferente,
tienen una comprensión del cliente
y otra comprensión del cliente.
Y cada vez que he visto
los esfuerzos para intentar
y unificar la visión
de todos los clientes,
se necesitan 20 personas en una habitación
y nadie llegará a ningún tipo de acuerdo,
porque todos tienen razón
y todos están equivocados.
Cuando hablas con el
otro lado del negocio.
Así que para evitar caer demasiado en
cientos y cientos de campos
de reuniones laboriosas,
tratando de reducir el alcance un poco
y hacer el esfuerzo de
intentar simplificar las cosas
y evitar la repetición,
hacerlo por dominio es
probablemente algo más factible.
Y en general, esto no
debería ser algo que intentes
planear los próximos 10 años de cambios
y empezar a construir
cada una de las opciones
porque las posibilidades son,

Japanese: 
では、貴社には
個別の部署か個別のサイロが点在しています。
そういう組織サイロがあることは
理由があるでしょう。
異なる言語を話しますから、
顧客に対する考え方が異なります。
皆の顧客に対する考え方を一つにしようとする
活動が毎回見られます。
部屋に20人がいて、
ビジネスの向こう側と話すと、
皆が正しくて皆が間違っているから
誰も合意していません。
手間のかかる会議につながる
数百のフィールドについて詳細に話すことを避けるために、
範囲を少し狭めて、
物事を簡素化して
繰り返しを避けようとして下さい。
ドメイン別にした方が実施可能になるでしょう。
全体的には、ここで10年の変更を計画して
あらゆる可能な選択肢を
検討してみるのではありません。
プロジェクトは数ヶ月後に

English: 
So if you've got different
departments or different silos
that have sprung up in your organization.
Chances are those organizational silos
are there for a reason.
Because they talk different language,
they have one understanding of customer
and another understanding of customer.
And every time I've seen efforts to try
and unify everyone's view of customer,
it's going to take 20 people in a room
and no one will get to
any sort of agreement,
because everyone's right
and everyone's wrong.
When you talk to the other
side of the business.
So in order to avoid getting too down into
hundreds and hundreds of fields
worth of laborious meetings,
trying to narrow the scope a bit
and making the effort to
try and simplify things
and avoid repetition,
making it per domain is probably
a more achievable thing.
And overall, this should not
be something that you try
and plan out the next 10
years worth of changes here
and start building out every single option
because chances are,

Portuguese: 
Você tem departamentos diferentes
espalhados pela organização.
As chances são de que essas divisões
existam por um motivo.
Porque falam diferentes línguas,
têm um entendimento de cliente
e outro entendimento de cliente.
Sempre que vi esforços para isso
e unifica a exibição do cliente,
e vai ter 20 pessoas em um salão
e ninguém vai concordar
porque todos têm razão e não têm.
Quando você fala com o
outro lado do negócio.
Para evitar abaixar muito
centenas e centenas de
campos vindo de reuniões
tentando estreitar o alcance
e fazendo um esforço para
simplificar as coisas
e evitar repetição,
fazer por domínio é melhor.
E você não deve tentar isso
e planeja os próximos dez anos de mudança
e construindo cada opção
porque as chances são

French: 
Si vous avez différents
départements ou différents silos
qui sont apparus dans votre organisation,
il y a de fortes chances que
ces silos organisationnels
existent pour une raison.
Puisqu'elles parlent un langage différent,
elles ont une compréhension du client
et une autre compréhension du client,
et j'ai à chaque fois vu
des efforts pour essayer
d'unifier la vision
que chacun a du client.
On aura beau avoir 20
personnes dans une pièce
que personne ne parviendra à un accord,
car tout le monde a raison
et tout le monde a tort,
quand vous interrogez le
reste de l'entreprise.
Pour éviter de se lancer
dans des centaines et
des centaines de champs
justifiant des réunions laborieuses,
essayer de réduire un peu la portée
et faire l'effort de simplifier les choses
et éviter les répétitions.
Il est probablement plus
facile de procéder par domaine.
Dans l'ensemble, vous
ne devriez pas essayer
de planifier les changements
pour les dix prochaines années
et commencer à élaborer chaque option,
car il y a de fortes chances que

German: 
Wenn also verschiedene Abteilungen oder
Unternehmenssilos in der
Organisation entstanden sind,
gibt es diese Unternehmenssilos
wahrscheinlich
aus gutem Grund.
Weil sie eine eigene Sprache sprechen,
weil sie ein eigenes
Verständnis davon haben,
was einen "Kunden" ausmacht.
Und bei allen Versuchen,
die ich gesehen habe, alle
Bedeutungen von "Kunde" im
Unternehmen zu vereinheitlichen,
müssen 20 Leute in einem
Raum zusammenkommen und
niemand wird zu einer Übereinkunft kommen,
weil jeder richtig liegt
- und jeder falsch,
wenn man mit der anderen Seite
des Unternehmens spricht.
Um also übermäßige Bemühungen
zu ersparen, aberhunderte
an mühsamen Konferenzen abzuhalten
und stattdessen den
Umfang etwas einzugrenzen,
die Dinge zu vereinfachen
und Redundanz zu vermeiden,
ist eine Aufteilung auf Abteilungen
die realistische Lösung.
Insgesamt sollten Sie bei
dieser Kategorisierung nicht
versuchen, die kommenden
10 Jahre an Veränderungen
vorherzusehen und jede
einzelne Option auszubauen,
denn zu erwarten ist,

Japanese: 
同じ環境ではない
可能性が高いですから。
だから、何を計画しても、それを捨ててやり直してしまいます。
これを一から作ることも
重要です。
そうすると、ある時期に
納品すへき量を制限し、
複雑性を削減し、もっと実施可能になります。
それで、変更に対応できるようになります。
ここのシステムにたくさんの機能を搭載して
6ヶ月後にシステムが
廃止されることが分かると、
分析と設計に
努力をたくさん
無駄したことになります。
まあ、必要なものだけを作りましたから
そんなことを避けました。
私の好きなもう一つの原則は
「それが要らないだろう」ということです。
だから、必要なものだけを作ります。
「作成」「取得」「更新」「削除」を
全部作るなら、
もしかして「作成」を使用する人がいないかなとか、
もしかして「削除」を使用する人がいないかなとか、
まあ、その機能は、製造段階で
テストしなければリスクとなり、
一回も使用しない

German: 
dass die Unternehmenslandschaft
mehrere Monate nach
Projektbeginn nicht konstant bleiben wird.
Was immer Sie vorausplanen,
müssen Sie dann
verwerfen und neu machen.
Der Aufbau von unten nach oben
ist auch wichtig.
Damit gibt es ein Limit, wie viel Sie
zu einem bestimmten
Zeitpunkt liefern können,
reduziert die Komplexität,
macht es erreichbarer.
Und heißt, dass Sie auf
Änderungen reagieren können.
Wenn Sie sehr viel Funktionalität
in das System einbauen, und dann
in 6 Monaten sehen,
dass das System stillgelegt wird,
haben Sie sich umsonst mit
Analysen und Design herumgeschlagen.
Sie vermeiden das, wenn Sie nur aufbauen,
was Sie brauchen.
Noch ein Grundsatz, den ich mag, ist:
Sie werden es nicht brauchen.
Bauen Sie nur auf, was Sie brauchen.
Wenn Sie etwas ausbauen,
erstellen, abrufen, updaten, löschen,
dann braucht vielleicht
niemand das Erstellen,
vielleicht braucht niemand das Löschen.
Okay, also diese
Funktionalität ist ein Risiko,
wenn sie nicht in der
Produktion getestet wird
und sie bedeutet auch technische Schulden,

English: 
it's not going to be the same landscape,
several months into the project.
So whatever you planned, you'll
have to throw away and redo.
So building this from the ground up
is an important thing as well.
That puts a limit on how much
you have to deliver at any given time,
reduces the complexity
makes it more achievable.
And means that you can respond to changes.
So if you build out a
whole lot of functionality
for this system here, and then you find
six months down the track
that this system is being decommissioned,
all of that wasted effort that you spent
doing analysis and design.
Well, you've avoided that
because you only built out
what you need.
So another principle here, that I like is,
You Ain't Gonna Need It.
So only build out what you need.
So if you're going to build out,
create, retrieve, update,
delete for everything,
then maybe no one's gonna use the Create,
maybe no one's gonna use the Delete.
Okay, so that functionality,
if it's not tested in production is a risk
and it is also then technical debt

French: 
l'environnement ne soit pas le même,
plusieurs mois après le début du projet.
Alors, quoi que vous ayez planifié,
vous devrez le balancer et le refaire.
La développer à partir de zéro
est également un point important.
Cela limite la quantité
de travail à fournir à un moment donné,
réduire la complexité rend
le projet plus réalisable
et vous permet de réagir aux changements.
Si vous déployez une
pléthore de fonctionnalités
pour ce système et que vous
découvrez, six mois plus tard,
que ce dernier est en
cours de démantèlement,
tous ces efforts inutiles
que vous avez consacrés
à l'analyse et à la conception,
vous les aurez évité, car
vous n'aurez déployé que
ce qu'il vous faut.
C'est dont un autre
principe que j'apprécie,
Vous n'En Aurez Pas Besoin.
Alors, ne déployez que ce qu'il vous faut.
Si vous voulez développez
Créer, Récupérer, Mettre à
jour, Supprimer, pour tout--
Peut-être que personne
n'utilisera la fonction Créer,
peut-être que personne
n'utilisera la fonction Supprimer.
Cette fonctionnalité,
si elle n'est pas testée en
production, est un risque
et c'est aussi une dette technique,

Spanish: 
que no va a ser el mismo escenario
luego de varios meses en el proyecto.
Sea lo que sea que hayas planeado,
tendrás que tirarlor y rehacerlo.
Así que construir esto desde cero
es una cosa importante también.
Eso pone un límite a la cantidad
tienes que entregar en cualquier momento,
reduce la complejidad
y lo hace más factible.
Y significa que puedes
responder a los cambios.
Así que si construyes una
gran cantidad de funcionalidad
para este sistema de aquí,
y luego seis meses más adelante
este sistema está siendo desmantelado,
todo ese esfuerzo
desperdiciado que gastaste
haciendo análisis y diseño.
Bueno, has evitado eso
porque sólo construiste
lo que necesitas.
Así que otro principio
aquí, que me gusta es,
No lo vas a necesitar.
Así que sólo construye lo que necesites.
Así que si vas a construir,
crear, recuperar,
actualizar, borrar para todo,
entonces tal vez nadie
va a usar el "Crear",
tal vez nadie va a usar el Borrador.
Bien, entonces esa funcionalidad,
si no se prueba en la
producción es un riesgo
y también es entonces la deuda técnica

Portuguese: 
de não ter o mesmo ambiente,
muitos meses no projeto.
Então o que planejou, vai ter que refazer.
Construir do zero
também é importante.
Isso limita o quanto
você entrega
e reduz a complexidade.
Quer dizer que você responde a mudanças.
Se tiver mais funcionalidade
para o sistema
e achar seis meses
.
.
.
.
.
.
.
.
..
.
.
.
.
.
..

French: 
parce que vous assumez et
intégrez une fonctionnalité
que vous n'utiliserez peut-être jamais
et que vous devez quand
même prendre en charge.
Pour éviter cela, il faut la
développer au fur et à mesure,
et c'est ce que nous
essayons de faire ici.
Nous commençons donc par
chaque cas d'utilisation,
en déployant l'environnement,
nous déterminons ce que
nous devons intégrer
et ce que nous devons modifier,
puis nous le superposons
de manière à obtenir ces différentes
applications pour vos différentes API.
Les API de processus.
Je pense que c'est suffisant
pour le genre de choses
que vous pourriez avoir là.
Parlons des commandes.
Supposons que nous
ayons plusieurs systèmes
dans lesquels se trouvent les commandes.
C'est très courant pour
pouvoir rassembler les données.
Certaines commandes pourraient
se trouver dans ce système-ci
et que les autres soient par ici
en fonction de la région géographique.
Il se peut que certains champs
soient dans ce système-ci
et d'autres dans ce système-là,
du coup, la logique d'agrégation
a besoin d'une source

Spanish: 
porque estás llevando y
construyendo la funcionalidad
que tal vez nunca uses
y que todavía tienes que hacer.
Así que para evitar eso,
constrúyelo sobre la marcha.
Y eso es lo que intentamos hacer aquí.
Así que estamos empezando
con cada caso de uso,
construyendo el paisaje,
trabajando en lo que
necesitamos construir,
y lo que necesitamos modificar,
y luego la superpones para
que obtengas esos diferentes
propósitos para tus diferentes API's.
Entonces, los procesos de API.
Creo que es suficiente
sobre el tipo de cosas
que podrías tener allí.
Hablemos de las órdenes.
Ahora, digamos que
tenemos múltiples sistemas
en que viven las órdenes.
Esto es algo común que puede que necesites
para reunir datos.
Y podría ser
que algunas de las órdenes
estén en este sistema
y las otras están aquí basadas
en la región geográfica.
Podría ser que algunos de los
campos estén en este sistema
y algunos están en este sistema,
así que la lógica de
agregación necesita un hogar

Japanese: 
機能を構築するから
その技術的な債務もあります。
しかも、サポートしなければいけません。
それを避けて、必要に応じて構築するのです。
それはここでやろうとしています。
各使用例から始めて、
環境を構築し、
何が必要なのか
何を変更すべきなのかを検討し、
そしてそれぞれのAPIの様々な目的に
対応するために階層化します。
では、プロセスAPIですね。
その説明で
十分だと思います。
注文について話しましょう。
さ、注文が所在する
複数のシステムがあるとしましょう。
これはデータを集めるために必要な
共通のものなのかもしれません。
一部の注文がこのシステムに所在し、
もう一部が地域によってここにあるかもしれません。
もしかして一部のフィールドがこのシステムにあり、
もう一部がこのシステムにあるから、
集計ロジックが居場所を必要とし、

Portuguese: 
porque
.
.
.
.
.
.
..
.
.
.
.
.
.
.
.
.
.
Para unir dados.
.
.
.
.
.

English: 
because you are carrying
and building functionality
that you may never use.
And you still have to support.
So avoiding that, build it as you go.
And that's what we're tryna do here.
So we're starting with each use case,
building out the landscape,
working out what we need to build,
and what we need to modify,
and then layering it so
that you get those different
purposes for your different API's.
Okay, so process API's.
Think that's enough on
the sort of things that
you might have there.
Let's talk about orders.
Now, let's say we've got multiple systems
that orders live in.
Okay, this is a common
thing that you may need
to bring together data.
And it could be that some of
the orders are in this system,
and the others are over here
based on geographic region.
It could be that some of the
fields are in this system
and some are in this system,
so the aggregation logic needs a home

German: 
weil Sie eine Funktionalität herstellen,
die Sie vielleicht nie verwenden.
Aber dennoch unterstützen müssen.
Um das zu vermeiden, bauen
Sie nur auf, was Sie brauchen.
Und das versuchen wir hier zu tun.
Wir beginnen mit jedem Anwendungsfall,
erstellen die Umgebung,
erarbeiten uns, was wir aufbauen müssen,
was wir ändern müssen
und legen es auf Ebenen,
damit wir die verschiedenen
Ziele für die verschiedenen APIs haben.
Okay, also Prozess-APIs.
Ich glaube, das ist genug
über die Dinge, die
Sie hier haben könnten.
Besprechen wir die Bestellungen.
Nehmen wir an, wir haben mehrere Systeme,
in denen sich Bestellungen befinden.
Okay, das kommt häufig vor,
wenn Sie Daten zusammenfassen müssen.
Es könnte sein, dass einige
Bestellungen in diesem System
und andere dort sind, je
nach geografischer Region.
Es könnte sein, dass einige
Felder in diesem System
und ein paar andere in diesem System sind.
Daher braucht die
Aggregationslogik einen Platz,

Spanish: 
y eso es lo que tenemos
a nivel de proceso.
Si pongo estas otras aplicaciones aquí,
si esto fuera
un sistema de orden,
y lo llamaremos ABC,
y esto es DEF,
entonces puedes descubrir
que cuando intentas reunir
la información de tus pedidos
de estos sistemas,
vas a tener el mismo nombre aquí,
pero puede que quieras ponerle
el prefijo del nombre del sistema,
porque esto es específico de este sistema
y esto es específico de este sistema.
Así que la lógica de
recuperación para esto
es bastante diferente a esto.
Así que para no enturbiar esto
y abarcar demasiado,
lo dividimos en diferentes API's.
Así que eso sería en
este caso, esto es DEF
y este es ABC.
Bien, ahora esta capa inferior
es el sistema
API's.

Japanese: 
それはプロセスレベルで提供します。
他のアプリをここに置くなら、
例えば、
これは注文システムで、
これをABC、
これをDEFと呼びましょう。
で、これらのシステムから
注文情報を
集めようとすると、
ここで同じ名前があるけれども、
これがこのシステムに固有、
これがこのシステムに固有だから
その先頭にシステム名を付けたいかもしれません。
だから、この検索ロジックがちょっと異なります。
これを分かりやすくするために、
個別のAPIに分割します。
よし、この場合は、これがDEF、
これがABCです。
それで、この下のレイヤーは
システムAPI
となります。

German: 
und den finden wir auf der Prozessebene.
Wenn ich die anderen
Anwendungen hier ablege,
wenn das ein A wäre,
das ist ein Ordnungssystem,
und wir nennen es ABC,
und dieses hier DEF,
und Sie sehen vielleicht,
wenn Sie Ihre Bestellinformationen
in diesen Systemen zusammenfassen,
dass Sie hier denselben Namen haben,
aber Sie könnten es mit
einer Vorsilbe markieren,
die spezifisch für das eine System
und spezifisch für das andere System ist.
Die Abruflogik dafür
unterscheidet sich sehr.
Um das nicht zu verändern
und es wirklich aufzubauschen,
machen wir verschiedene APIs daraus.
Also das wäre in diesem Fall DEF
und die andere ist ABC.
Auf dieser unteren Ebene
sind die System-
APIs.

English: 
and that's what we've
got at the process level.
If I put these other apps in here,
if this was a,
this is an order system,
and we'll call this one ABC,
and this is DEF,
then you may find that
when you're trying to bring
together your orders information
out of these systems,
you're gonna have the same name here,
but you may wanna prefix it
with the name of the system,
because this is specific to this system
and this is specific to this system.
So the retrieval logic for this
is quite different to this.
So in order to not muddy up this
and get this really bloated,
we break it into different API's.
All right, so that would be
in this case, this is DEF
and this one's ABC.
Okay, now this bottom layer
is the system
API's.

French: 
et c'est ce que nous avons
au niveau du processus.
Si je mets ces autres applications ici,
si c'était un--
c'est un système de commandes,
nous appellerons celui-ci ABC,
et celui-là DEF,
alors vous pourriez constater que
lorsque vous essayez de rassembler
vos informations de commandes,
en dehors de ces systèmes,
vous aurez le même nom ici,
mais pourriez vouloir le
préfixer avec le nom du système,
parce que ceci spécifique à ce système-ci
et ceci est spécifique à ce système-là.
La logique de récupération pour ceci
est donc très différente de celle-ci.
Alors, pour ne pas compliquer
et disproportionner cela,
nous les divisons en différentes API.
Très bien, dans ce
cas-ci, il s'agit de DEF
et dans celui-là, de ABC.
Maintenant, cette couche inférieure est
l'API du système.

Portuguese: 
.
.
.
.
.
.
.
.
.
.
.
Porque é específico do sistema.
.
.
.
.
.
Nesse caso seria o DEF
e nesse o ABC.
.
.
.

Portuguese: 
.
.
.
.
.
.
.
Sugiro que é um bom começo,
por sistema.
.
.
.
Se tiver um legado
com duas áreas funcionais diferentes,
você pode manter
de jeito simples.
.
.
.
.
.
.
.
.
.

Spanish: 
Al igual que los procesos API,
estamos tratando de
conseguir la reutilización,
estamos tratando de crear un
hogar para la funcionalidad
que habla con un sistema.
Ahora una pregunta común que me hacen es,
¿qué deberíamos hacer a este nivel?
¿Debería ser uno por sistema?
¿Debería ser de grano más
fino, de grano más grueso?
Ciertamente sugeriría que
un buen punto de partida
es por sistema.
Y si se trata de un sistema
particularmente complejo,
tal vez quieras separarlo más.
Separarlo por los dominios que
viven dentro de ese sistema.
Así que si tuvieras un sistema de legado
que tiene dos áreas
funcionales diferentes,
puede que por razones de mantenerlo
simple.
Lo dividas en diferentes API's.
Pero un buen punto de partida es pensar
para cada sistema con
el que hablo necesito
al menos una API del sistema,
necesito al menos uno.
Uno o más por cada sistema
con el que estás hablando.
Entonces y luego veamos la
pila de llamadas general aquí.
Si tengo el cliente,
llamando a su Experiencia API,
entonces hace llamadas a un proceso API,

Japanese: 
プロセスAPIと同様に、再使用してみます。
システムと通信する機能の居場所を
作ろうとしています。
よくある質問は、このレベルで
どうすればいいのかということです。
これはシステムあたり1つなのか？
さらに詳細にするか、それとも一般的にするか？
確かに、システム別は
理想的な出発点だと思います。
これが特に複雑なシステムだったら、
さらに解体した方がいいかもしれません。
システム内に所在するドメイン別に分けるのです。
機能上のエリアが2つある
レガシィシステムがあれば、
それを簡単なままにする
理由があるかもしれません。
個別のAPIに分けたりします。
通信先のシステムにつき少なくとも
一つのシステムAPIが必要だという考え方は
理想的な出発点だと思います。
通信先のシステムにつき一つ以上。
では、全体的なコールスタックを見てみましょう。
クライアントが
体験APIを呼び出して
プロセスAPI、そしてプロセスAPIを

German: 
Wie bei den Prozess-APIs versuchen wir
einen Platz für die
Funktionalität zu erstellen,
die mit dem System interagiert.
Eine häufige Frage an mich ist,
was man auf dieser Ebene tun sollte?
Sollte es eine pro System sein?
Sollte sie feiner oder gröber sein?
Ich schlage vor, dass pro System
ein guter Ausgangspunkt ist.
Wenn es ein besonders
komplexes System ist,
könnte man es weiter aufschlüsseln.
Nach Domänen, die im
System enthalten sind.
Wenn man ein vorhandenes System
mit zwei verschiedenen
Funktionsbereichen hat,
könnte man es, wenn man es bewahren will,
unkompliziert machen.
Auf verschieden APIs verteilen.
Aber ein guter Ausgangspunkt ist,
das es für jedes System, das
ich aufrufe, eine System-API,
zumindest eine System-API gibt.
Eine oder mehrere pro
System, das Sie aufrufen.
Okay, sehen wir uns
den Call-Stack hier an.
Wenn der Client
seine Experience-API aufruft,
führt er Aufrufe auf
einer Prozess-API durch,

French: 
Tout comme les API de processus,
nous essayons de les réutiliser,
nous essayons de créer une
source pour les fonctionnalités
qui communiquent avec un système.
Une question qui revient souvent est :
que devons-nous faire à ce niveau ?
Cela devrait-il être d'un par système ?
Faut-il que la granularité soit
plus fine, plus grossière ?
Je pense qu'un bon point de départ
est par système,
et s'il s'agit d'un système
particulièrement complexe,
vous pouvez vouloir le
fragmenter davantage.
Il faut donc le fragmenter en domaines
se trouvant à l'intérieur de ce système.
Si vous avez un système hérité
qui a deux domaines
fonctionnels différents,
vous pouvez, pour des
raisons de simplicité,
le décomposer en différentes API,
mais un bon point de
départ est de penser que
pour chaque système avec
lequel je communique,
j'ai besoin d'une API système au moins,
j'en ai besoin d'une au moins,
une ou plusieurs par système
avec lequel vous communiquez.
Ensuite, analysons la pile
d'appels dans son ensemble.
Si j'ai le client qui
appelle son API d'expérience,
alors il fait des appels
sur une API de processus

English: 
So just like process API's,
we're tryna get reuse,
we're trying to create
a home for functionality
that talks to a system.
Now a common question I get is,
what should we do at this level?
Should this be one per system?
Should this be more fine
grained, more coarse grained?
I'd certainly suggest
that a good starting point
is per system.
And then if it is a
particularly complex system,
you may wanna break it apart more.
So breaking it by the domains
that live inside that system.
So if you had a legacy system
that has two different functional areas,
you may for reasons of keeping it
keeping it simple.
Break it into different API's.
But a good starting point is think
for each system I talk to I
need a system API at least,
I need at least one.
So one or more per system
that you're talking to.
Okay, so and then let's look
at the overall call stack here.
if I've got the client,
calling its Experience API,
then it makes calls on a process API,

English: 
and then the process API it
may make one or more calls to
system API's,
which then make calls
down to those systems.
So, and this sort of shows
some of the things you
might need to consider.
So my tips on this,
don't try and have just
application at the top,
or at the bottom,
if it is both client and server,
put the box in both places.
Start with one per system
that you're talking to
at the system API level,
and break apart if it gets
too complex, because remember,
you're shielded by the process API's.
So the process API is if
you need to break apart
this API into multiple API's.
This is the the client
in this case of a an API.
So this might need some changes,
but it shouldn't ripple on to
the rest of the organization.
Now, if you build this as you're going
stick into to the YAGNI principle,
then as you bring on new types
of use cases or new systems,
you should be able to then make use

German: 
und die Prozess-API ruft einmal oder öfter
die System-APIs auf,
die dann die Systeme aufrufen.
Das zeigt irgendwie
einige der Dinge, die
zu berücksichtigen sind.
Meine Tipps dazu sind,
nicht zu versuchen, nur oben
oder unten Anwendungen zu haben,
sondern legen Sie Client und
Server oben und unten ab.
Beginnen Sie mit einer pro System, die Sie
auf System-API-Ebene aufrufen,
und teilen Sie sie auf,
wenn sie zu komplex wird,
weil Sie von den Prozess-APIs
abgeschirmt sind.
Also Prozess-API, wenn sie
die API auf mehrere APIs aufteilen müssen.
Das ist in diesem Fall der API ein Client.
Es könnten Änderungen erforderlich sein,
aber sie sollten die übrige
Organisation nicht betreffen.
Wenn Sie das Schritt für Schritt aufbauen,
halten Sie sich an den YAGNI-Grundsatz,
und wenn Sie neue Anwendungsfäle
oder Systeme einbringen,
sollten Sie dafür

Spanish: 
y luego el proceso API puede
hacer una o más llamadas
al API del sistema,
que luego hace llamadas a esos sistemas.
Así que, esto muestra
algunas de las cosas que
podrías necesitar considerar.
Así que mis consejos sobre esto,
no intentes tener sólo una
aplicación en la parte superior,
o en el fondo,
si es a la vez cliente y servidor,
pon la caja en ambos lugares.
Empieza con uno por cada sistema
con el que estés hablando
a nivel de la API del sistema,
y desglosa si se vuelve demasiado
complejo, porque recuerda,
estás protegido por el proceso API.
Así que en el proceso
API si necesitas separar
esta API en múltiples API.
Este es el cliente en
este caso de una API.
Por lo tanto, es posible que
esto necesite algunos cambios,
pero no debería afectar al
resto de la organización.
Ahora, si construyes esto como vas a hacer
apegándote al principio de YAGNI,
entonces a medida que se
introducen nuevos tipos de casos
de uso o nuevos sistemas
deberías ser capaz de hacer uso

French: 
et l'API de processus peut
faire un ou plusieurs appels aux
API système
qui font ensuite des
appels vers ces systèmes.
Ça montre en quelque sorte
certains éléments à prendre en compte.
Mes conseils à ce sujet :
n'essayez pas de n'avoir
qu'une application en haut
ou en bas.
Si c'est à la fois un
client et un serveur,
mettez la case aux deux endroits.
Commencez avec une par système
avec lequel vous communiquez
au niveau de l'API système,
et fragmentez si ça devient trop complexe,
car n'oubliez-pas,
vous êtes protégé par
les API des processus.
L'API de processus sert donc à fragmenter
cette API en plusieurs API.
Il s'agit, dans ce cas-ci,
du client d'une API.
Cela peut donc nécessiter des changements,
mais cela ne doit pas se répercuter
sur le reste de l'organisation.
Si vous la développez en
appliquant le principe YAGNI,
alors que vous introduisez
de nouveaux types
de cas d'utilisation ou
de nouveaux systèmes,
vous devriez pouvoir utiliser

Portuguese: 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Se fizer isso no fluxo,
siga o princípio YAGNI,
então ao trazer novos
tipos de casos ou sistemas,
deve conseguir usar

Japanese: 
呼び出す場合は、システムAPIを何回か呼び出し、
システムAPIが
それらのシステムを呼び出すかもしれません。
これで、検討すべき点が
ちょっと明らかになります。
アプリケーションを
上か下に配置するのではない
ということをお勧めします。
クライアントとサーバーの両方の役割を果たす場合は、箱を両方の場所に置いて下さい。
システムAPIレベルで通信先となる
システムにつき一つということから始めて、
複雑すぎるなら分割して下さい。
プロセスAPIで遮断されているからご留意ください。
では、プロセスAPIは、このAPIを
複数のAPIに分割する必要がある場合ですね。
APIの場合はこれがクライアントとなります。
何か変更する必要があるかもしれませんけど、
組織全体に広がるわけではありません。
では、YAGNI原則に従って
これを作れば、
新しい使用例か新しいシステムを取り上げる時に、
既存の機能を

Japanese: 
使用できるはずです。
そして、プロジェクトの一環として
追加の機能を入れる必要があれば、
その機能を既存のAPIに追加できます。
これはプレースホルダだから。
それは取引とかやるべきことは
全く違う可能性がありますから、
プロジェクトに追加するものは
既存の環境の上に載せられる必要があります。
必要なものだけを作っていいです。
これで、私の3層アーキテクチャーについての
ヒントが分かるでしょう。

Portuguese: 
a funcionalidade existente.
Se houver funcionalidade extra
que você precise colocar
como parte do projetos,
pode adicionar a funcionalidade
a um API existente,
porque é um marcador, se quiser.
Podem ser coisas diferentes
que você precisa para transações.
O que você somar ao processo
pode ir para seu ambiente existente.
Pode construir o que precisar.
Espero que aproveite minhas dicas
sobre a arquitetura em trës camadas.

French: 
les fonctionnalités existantes,
et si vous devez ajouter
d'autres fonctionnalités
dans le cadre de votre projet,
vous pouvez soit ajouter
ces fonctionnalités
à une API existante,
car il s'agit d'un espace
réservé, si vous le souhaitez,
et il peut s'agir de choses
entièrement différentes
que vous devez faire, comme
des transactions, etc.
Tout ce que vous devez
donc ajouter au projet
peut se superposer à votre
environnement existant.
Vous pouvez développer exactement
ce dont vous avez besoin,
et j'espère que cela vous donnera une idée
de certains de mes conseils
concernant l'architecture à trois niveaux.

Spanish: 
de la funcionalidad existente.
Y si hay una funcionalidad extra
que necesitas poner como
parte de tu proyecto,
puedes añadir esa funcionalidad
a una API existente,
porque esto es un marcador
de posición si quieres.
Y podrían ser cosas
completamente diferentes que
tienes que hacer como
transacciones, y así sucesivamente.
Así que lo que necesites
añadir para el proyecto
puede superponerse a tu paisaje existente.
Puedes construir justo lo que necesitas.
Y espero que te dé alguna idea
sobre algunos de mis consejos
con la Arquitectura de Tres Capas.

German: 
die bestehende Funktionalität nutzen.
Wenn es eine zusätzliche
Funktionalität gibt,
die ein Teil Ihres Projekts ist,
können Sie sie zu einer
bestehenden API hinzufügen
weil sie als Platzhalter dient.
Sie könnten auch ganz andere Dinge
zu tun haben, wie Transaktionen usw.
Was Sie für das Projekt
auch hinzufügen müssen,
kann ihre bestehende Umgebung überlagern.
Sie können einfach
aufbauen, was Sie brauchen.
Und hoffentlich erhielten Sie
einige Ideen durch meine Tipps
mit der 3-stufigen Architektur.

English: 
of existing functionality.
And if there is extra functionality
that you need to put in
as part of your project,
you can either add that
functionality to an existing API,
cause this is a placeholder if you like.
And it could be entirely different things
that you need to do like
transactions, and so on.
So whatever you need
to add for the project
can overlay onto your existing landscape.
You can build just what you need.
And hopefully it gives you
some idea on some of my tips
with the Three-layered Architecture.
(whooshing)
