fix: update links and remove .html extension

This commit is contained in:
Mathias Schopmans
2024-03-12 11:42:36 +01:00
committed by Mathias Schopmans
parent bc1e5b2d70
commit daa86a3f59
75 changed files with 103 additions and 103 deletions

View File

@@ -10,7 +10,7 @@ Anypoint provides tools to use Enterprise Integration Patterns (EAI) and has a h
Anypoint Community Version is Open Source and contribution is possible.
The platform is pluggable with own connectors.
Mulesoft is also driving the [RAML](/tools/raml.html) specification and related Open Source tools.
Mulesoft is also driving the [RAML](/languages-and-frameworks/raml/) specification and related Open Source tools.
AOE is a Mulesoft Partner and we use both the Community and Enterprise Versions of Anypoint.
We use Anypoint as an API Gateway to combine and transform data from multiple backends.

View File

@@ -12,8 +12,8 @@ Furthermore, as one of the most important design aspects is consistency, one can
It also helps speed up parallel implementation.
A team that consumes the API can start working directly after the API design because it can easily be mocked.
There are several tools for modelling an API, but here at AOE we mainly use [RAML](/tools/raml.html) as it provides a rich set of tools for generating documentation, mocking and more.
For mocking we use [WireMock](/tools/wiremock.html), for example.
There are several tools for modelling an API, but here at AOE we mainly use [RAML](/languages-and-frameworks/raml/) as it provides a rich set of tools for generating documentation, mocking and more.
For mocking we use [WireMock](/tools/wiremock/), for example.
Related to the "API-First" approach is the "Headless" approach where an existing application (with or without existing API) is used as a backend for a separate frontend.
We used this with sucess for Magento-based E-Commerce platforms.

View File

@@ -32,4 +32,4 @@ The configuration is really simple due to the [plugin system](http://babeljs.io/
To know what you need you can practice ECMAScript 6 by doing it with [es6katas](http://es6katas.org/) and ask [caniuse](http://caniuse.com/).
If you are using [TypeScript](/languages-and-frameworks/typescript.html), Babel is not necessary since you already get the new features with TypeScript.
If you are using [TypeScript](/languages-and-frameworks/typescript/), Babel is not necessary since you already get the new features with TypeScript.

View File

@@ -8,7 +8,7 @@ Consul is a lightweight service to provide a service discovery registry with fai
The typical way to use it is that a consul master cluster takes care of the update and write processes and consul clients run locally on the apps host - data is shared across the complete Consul cluster.
The data can be accessed by using DNS and HTTP APIs.
At AOE, we use Consul for settings distribution with consul-template as a way to do [Settings Injection](/methods-and-patterns/settings-injection.html) during deployment.
Consul is also used as service discovery between apps inside [microservice](/methods-and-patterns/microservices.html) environments.
At AOE, we use Consul for settings distribution with consul-template as a way to do [Settings Injection](/methods-and-patterns/settings-injection/) during deployment.
Consul is also used as service discovery between apps inside [microservice](/methods-and-patterns/microservices/) environments.
With Vault there is another tool that can be used to manage and share secrets.

View File

@@ -4,11 +4,11 @@ ring: trial
quadrant: methods-and-patterns
---
In [Microservices](/methods-and-patterns/microservices.html) we have already covered the trend that modern architectures are moving away more and more from big monolithic applications to distributed software suites.
In [Microservices](/methods-and-patterns/microservices/) we have already covered the trend that modern architectures are moving away more and more from big monolithic applications to distributed software suites.
The result of splitting our software and infrastructure in smaller parts, is the need to communicate with each other.
This can be done by direct communication or by message-based asynchronouous communication.
While synchronuous communication allows for more plannable "real-time" response times of the overall systems, asynchronouos communication increases the resilience and stability of the system significantly and allows one to use other integration and scaling patterns. However, it often comes with additional complexity.
Most of the IaaS Cloud providers offer messaging services such as AWS SQS which provide the possibility to decouple our infrastructure via Messaging.
Also, we use [RabbitMQ](/tools/rabbitmq.html) as a Messaging and Broker solution within our applications.
The decision of using messaging and messaging patterns as an integration strategy can be made as part of [strategic design](/methods-and-patterns/strategic-domain-driven-design.html) considerations.
Also, we use [RabbitMQ](/tools/rabbitmq/) as a Messaging and Broker solution within our applications.
The decision of using messaging and messaging patterns as an integration strategy can be made as part of [strategic design](/methods-and-patterns/strategic-domain-driven-design/) considerations.

View File

@@ -13,6 +13,6 @@ In a DevOps environment, this helps a lot as we can run the exact same software
Also, Docker allows us to keep our development setup much smaller and faster; instead of VirtualBox setups on a per-project base, we can compose our project development setup out of small containers.
A CI environment building the containers allows us to package and test the whole environment instead of different software components on different runtimes in a much more stable way.
Backed by services such as [Kubernetes](/platforms-and-aoe-services/kubernetes.html), we can deploy Docker containers on a flexible infrastructure and enable our developers to test their software more easily in different environments.
Backed by services such as [Kubernetes](/platforms-and-aoe-services/kubernetes/), we can deploy Docker containers on a flexible infrastructure and enable our developers to test their software more easily in different environments.
Here at AOE, we assess Docker in different projects to become more flexible and faster, which increases our focus on development of even better and more stable software.

View File

@@ -12,4 +12,4 @@ We used Flow in a couple of projects and decided to put it on hold for the follo
* limited documentation and community
* development of the framework is closely coupled to the progress of the Neos project
Although it could be that some of the above-mentioned aspects have improved in the past, we decided to use other PHP frameworks such as [Symfony](http://symfony.com/) or other Languages (See [Go](/languages-and-frameworks/go-lang.html); [Play Framework](/languages-and-frameworks/play-framework.html); [Spring Boot](/languages-and-frameworks/spring-boot.html))
Although it could be that some of the above-mentioned aspects have improved in the past, we decided to use other PHP frameworks such as [Symfony](http://symfony.com/) or other Languages (See [Go](/languages-and-frameworks/go-lang/); [Play Framework](/languages-and-frameworks/play-framework/); [Spring Boot](/languages-and-frameworks/spring-boot/))

View File

@@ -8,7 +8,7 @@ quadrant: tools
Out of the box, Gatling comes with excellent support of the HTTP protocol that makes it a tool of choice for load testing any HTTP server. As the core engine is actually protocol agnostic, it is perfectly possible to implement support for other protocols. For example, Gatling currently also ships [JMS support](http://gatling.io/docs/current/).
Gatling is built with [Scala Lang](/languages-and-frameworks/scala-lang.html) and [Akka](/languages-and-frameworks/akka.html). By making good use of Scala's native language features (such as as the extensive type system), it makes writing tests feel natural and expressive, instead of writing load tests based on a DSL encoded in some special syntax.
Gatling is built with [Scala Lang](/languages-and-frameworks/scala-lang/) and [Akka](/languages-and-frameworks/akka/). By making good use of Scala's native language features (such as as the extensive type system), it makes writing tests feel natural and expressive, instead of writing load tests based on a DSL encoded in some special syntax.
This allows us to use all native Scala features to work with, with the focus on the ability to structure your tests as pure code, and actually unit test your load tests.

View File

@@ -11,4 +11,4 @@ It uses a Groovy-based DSL to declaratively model your problem domain (Build aut
While providing plugins for building libs, apps and webapps in Java, Groovy and Scala out of the box it is not tied to the JVM as target platform, which is impressively shown by the native build support for C / C++.
At AOE, it is used in various places already: to build [Anypoint](/tools/anypoint-platform.html)- and [Spring Boot-](/languages-and-frameworks/spring-boot.html) based applications; to build Android Apps; to automate the creation of Jenkins Jobs; to create Docker images and Debian packages and also do some deployment scripting with it.
At AOE, it is used in various places already: to build [Anypoint](/tools/anypoint-platform/) and [Spring Boot](/languages-and-frameworks/spring-boot/) based applications; to build Android Apps; to automate the creation of Jenkins Jobs; to create Docker images and Debian packages and also do some deployment scripting with it.

View File

@@ -6,4 +6,4 @@ quadrant: languages-and-frameworks
Groovy is a dynamically typed compiled language running on the JVM. It is easy to learn as it provides a familiar syntax for Java programmers, but also offers advanced features such as closures and makes some mandatory Java syntax requirements optional to enhance the conciseness of the code. These features make Groovy especially well-suited for scripting and domain-specific languages. This is used by popular tools such as Gradle or Spock.
At AOE, Groovy is used in many projects and areas. We use Gradle as a build system, we carry out unit and integration testing with Spock and Geb, we generate Jenkins jobs with JobDSL and we implement complete services with Groovy and [Spring Boot](/languages-and-frameworks/spring-boot.html).
At AOE, Groovy is used in many projects and areas. We use Gradle as a build system, we carry out unit and integration testing with Spock and Geb, we generate Jenkins jobs with JobDSL and we implement complete services with Groovy and [Spring Boot](/languages-and-frameworks/spring-boot/).

View File

@@ -15,7 +15,7 @@ The benefits we see are:
* enabling better parallel work in big teams or multi-team projects
* flexibility in deploying changes to production - by just deploying the changed service
Related patterns are [Strategic Domain Driven Design](/methods-and-patterns/strategic-domain-driven-design.html) as an approach to wisely cut your architecture according to useful bounded contexts and decide on the relevant communication and "translation" between the services.
Related patterns are [Strategic Domain Driven Design](/methods-and-patterns/strategic-domain-driven-design/) as an approach to wisely cut your architecture according to useful bounded contexts and decide on the relevant communication and "translation" between the services.
In case you are looking for a small visualisation tool for your microservice architecture you might find [vistecture](https://github.com/AOEpeople/vistecture/) useful.
Also [Resilience thinking](/methods-and-patterns/resilience-thinking.html) is especially important when designing an application as a suite of microservices.
Also [Resilience thinking](/methods-and-patterns/resilience-thinking/) is especially important when designing an application as a suite of microservices.

View File

@@ -6,21 +6,21 @@ quadrant: tools
[npm](https://www.npmjs.com/) is one of, if not the most, popular package manager for JavaScript. Because of the big community, you can find nearly every dependency in npm.
Instead of other package managers such as [bower](/tools/bower.html), you have to write your packages as [modules](https://en.wikipedia.org/wiki/CommonJS). This unifies the way you have to use, test and, of course, understand dependencies.
Instead of other package managers such as [bower](/tools/bower/), you have to write your packages as [modules](https://en.wikipedia.org/wiki/CommonJS). This unifies the way you have to use, test and, of course, understand dependencies.
npm creates a tree for your dependencies and their nesting dependencies. Because of this, you don't need to handle version conflicts, since every dependency uses there own version of e.g. [webpack](/tools/webpack.html).
npm creates a tree for your dependencies and their nesting dependencies. Because of this, you don't need to handle version conflicts, since every dependency uses there own version of e.g. [webpack](/tools/webpack/).
With [shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap) you have a robust tool to lock down and manage the versions of your dependencies - following the [Pin (external) dependencies](/methods-and-patterns/pin-external-dependencies.html) approach.
With [shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap) you have a robust tool to lock down and manage the versions of your dependencies - following the [Pin (external) dependencies](/methods-and-patterns/pin-external-dependencies/) approach.
For each package you have to classify your dependencies:
- dependencies are needed for use without the need of pre compiling, e.g. [lodash](https://lodash.com/)
- devDependencies are needed for development only, e.g. testing frameworks or pre compiler e.g. [babel](/languages-and-frameworks/babel.html)
- devDependencies are needed for development only, e.g. testing frameworks or pre compiler e.g. [babel](/languages-and-frameworks/babel/)
- peerDependencies you have to provide for using the package
With [scripts](https://docs.npmjs.com/misc/scripts) you get support for the most common build lifecycle steps, e.g. build, start, test ...
Other useful features:
- mirror support for your own repository (e.g. [artifactory](/platforms-and-aoe-services/artifactory.html))
- can be used for server and client JavaScript development (see [node.js](/languages-and-frameworks/node-js.html) )
- mirror support for your own repository (e.g. [artifactory](/platforms-and-aoe-services/artifactory/))
- can be used for server and client JavaScript development (see [node.js](/languages-and-frameworks/node-js/) )

View File

@@ -10,6 +10,6 @@ One of the central features is that entities, which are to be managed within the
As with every framework or application, the general-purpose goals and abstraction comes with drawbacks: In fact, OroPlatform modifies and extends the common way of doing things in Symfony in several places, which makes the developer's life hard at times. Also, the UI and package managing are set in such a way that they are hard to extend or replace. The many additional abstraction layers can result in decreased performance.
On the other hand, OroPlatform gives you a good head start for prototyping and frees you from rebuilding common requirements - which makes it a relevant choice for business applications with the need to manage several entities in a backend. Also, projects such [Akeneo](/tools/akeneo.html) or OroCRM use OroPlatform with success.
On the other hand, OroPlatform gives you a good head start for prototyping and frees you from rebuilding common requirements - which makes it a relevant choice for business applications with the need to manage several entities in a backend. Also, projects such [Akeneo](/tools/akeneo/) or OroCRM use OroPlatform with success.
Since the project is still young, the future development and improvements need to be watched. We classified the Framework as ***Assess***.

View File

@@ -13,4 +13,4 @@ Here at AOE, we have numerous PHP projects, and we often kept it backwards-compa
Now, PHP 5 has reached its end--of-life, and it is time to discontinue the backwards-compatibility in favor of better and more stable applications.
Even though we can use the PHP 7 runtime while being PHP 5-compatible, it is not considered good practice anymore, as we can now rely on the PHP 7 features and use all of its advantages.
One of the major points PHP 7 supports is proper type hinting and return types (apart from PhpDocs), which makes [static analysis](/tools/phan.html) much easier and can improve the overall code quality significantly.
One of the major points PHP 7 supports is proper type hinting and return types (apart from PhpDocs), which makes [static analysis](/tools/phan/) much easier and can improve the overall code quality significantly.

View File

@@ -32,7 +32,7 @@ We suggest the following:
dependent packages are used.
* It's also suggested to use local or central caches for the retrieval of
packages. (E.g.
[artifactory as composer and npm cache](/platforms-and-aoe-services/artifactory.html))
[artifactory as composer and npm cache](/platforms-and-aoe-services/artifactory/))
For updating of dependencies define a process in the team. This can either be
done on the dev-system or in a separate automated CI job - both resulting in

View File

@@ -8,4 +8,4 @@ Continuous Integration and Delivery is a critical part of our development and de
Being an important part of each project, the pipeline configuration should be managed as code and rolled out automatically - this also allows us to manage the pipeline itself applying the same standards that apply to application code.
While some teams started using Jenkins' [JobDSL plugin,](https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin) others explored the new [Jenkins Pipeline](https://jenkins.io/doc/book/pipeline/) - in both ways, the build artifacts should be published to an artifact repository such as [Artifactory.](/platforms-and-aoe-services/artifactory.html)
While some teams started using Jenkins' [JobDSL plugin,](https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin) others explored the new [Jenkins Pipeline](https://jenkins.io/doc/book/pipeline/) - in both ways, the build artifacts should be published to an artifact repository such as [Artifactory](/platforms-and-aoe-services/artifactory/).

View File

@@ -4,7 +4,7 @@ ring: adopt
quadrant: languages-and-frameworks
---
The Play Framework is a lightweight (web)application framework for Java and [Scala](/languages-and-frameworks/scala-lang.html) programmers.
The Play Framework is a lightweight (web)application framework for Java and [Scala](/languages-and-frameworks/scala-lang/) programmers.
A developer can choose from different modules to include necessary functionality such s accessing http resources, databases, and so on. As a consequence, the developer can choose, and is not distracted by or clobbered with irrelevant things. This approach is considered as minimalistic, but it is easy to include necessary functionality.

View File

@@ -13,4 +13,4 @@ Sure, not all of them are useful, but the sheer number of plugins shows how easy
In fact, it´s just a matter of writing a single JS function.
Finally, PostCSS is very fast and easy to setup because it runs 100% in JavaScript.
Compared to [Sass](/languages-and-frameworks/sass.html) as a preprocessor, it feels much more powerful but at the same time less bloated with superfluous functionality because everything comes in its own little plugin
Compared to [Sass](/languages-and-frameworks/sass/) as a preprocessor, it feels much more powerful but at the same time less bloated with superfluous functionality because everything comes in its own little plugin

View File

@@ -9,7 +9,7 @@ Puppet
Puppet is an Open Source configuration management tool. It is used by a wide range of different companies world-wide, e.g. the Wikimedia Foundation, Mozilla, Reddit, CERN, Dell, Rackspace, Twitter, the New York Stock Exchange, PayPal, Disney, Citrix Systems, Spotify, Oracle, the University of California Los Angeles, the University of North Texas, QVC, Intel, Google and others.
Puppet has been the basic tool to address Continuous Configuration Automation (CCA) in AOE's [Infrastructure as Code](/methods-and-patterns/infrastructure-as-code.html) strategy (IaC) for more than 4 years.
Puppet has been the basic tool to address Continuous Configuration Automation (CCA) in AOE's [Infrastructure as Code](/platforms-and-aoe-services/infrastructure-as-code/) strategy (IaC) for more than 4 years.
Puppet Environments
-------------------

View File

@@ -6,8 +6,8 @@ quadrant: tools
RabbitMQ is an Open Source message broker - implementing the Advanced Message Queuing Protocol (AMQP) protocol. It provides a reliable and scalable way to transport data between loosely coupled applications, using different EAI patterns such as the Publish & Subscriber pattern. AMQP supports direct and fan-out exchanges (broadcasts) as well as topics. Queuing mechanisms allow for robust architectures, mitigating the risks of application downtimes. Typically, a RabbitMQ server can easily buffer millions of messages. RabbitMQ supports JMS in addition to AMQP. It is not intended to use JMS for new systems, but it makes RabbitMQ useful for integrating legacy systems.
There are several alternative solutions to RabbitMQ, e. g. the free Apache ActiveMQ, which is integrated in [Anypoint platform](/tools/anypoint-platform.html). ActiveMQ implements a somewhat simpler routing concept than RabbitMQ, but offers more protocols. Commercial products in this area are offered by IBM (Websphere MQ), Fiorano and almost every vendor of ESB products.
There are several alternative solutions to RabbitMQ, e. g. the free Apache ActiveMQ, which is integrated in [Anypoint platform](/tools/anypoint-platform/). ActiveMQ implements a somewhat simpler routing concept than RabbitMQ, but offers more protocols. Commercial products in this area are offered by IBM (Websphere MQ), Fiorano and almost every vendor of ESB products.
We use RabbitMQ internally for transferring messages safely in our logging ecosystem between [Logstash](/platforms-and-aoe-services/elk-stack.html) proxies and servers using direct and fan-out exchanges for delivering messages to appropriate destinations. RabbitMQ is also used to asynchronously trigger Jenkins jobs from our SCMs to mitigate heavy load on the SCMs, usually caused by Jenkins polls for SCM changes. Additionally, some critical events for monitoring are using RabbitMQ for guaranteed notification.
We use RabbitMQ internally for transferring messages safely in our logging ecosystem between [Logstash](/platforms-and-aoe-services/elk-stack/) proxies and servers using direct and fan-out exchanges for delivering messages to appropriate destinations. RabbitMQ is also used to asynchronously trigger Jenkins jobs from our SCMs to mitigate heavy load on the SCMs, usually caused by Jenkins polls for SCM changes. Additionally, some critical events for monitoring are using RabbitMQ for guaranteed notification.
RabbitMQ is rated "Trial". It fits into our approach to build robust, [resilient systems](/methods-and-patterns/resilience-thinking.html) and use [asynchronous messages](/methods-and-patterns/decoupling-infrastructure-via-messaging.html) for loosely coupled communications between components. In practice, RabbitMQ proved to be stable and dealt well with service interruptions from failures and maintenance slots. A common pain point is RabbitMQ as a single point of failure disrupting the data flow in a system. This issue is currently approached by setting up a HA cluster for RabbitMQ. The outcome of this approach will clarify the extent of future usage of RabbitMQ in our systems.
RabbitMQ is rated "Trial". It fits into our approach to build robust, [resilient systems](/methods-and-patterns/resilience-thinking/) and use [asynchronous messages](/methods-and-patterns/decoupling-infrastructure-via-messaging/) for loosely coupled communications between components. In practice, RabbitMQ proved to be stable and dealt well with service interruptions from failures and maintenance slots. A common pain point is RabbitMQ as a single point of failure disrupting the data flow in a system. This issue is currently approached by setting up a HA cluster for RabbitMQ. The outcome of this approach will clarify the extent of future usage of RabbitMQ in our systems.

View File

@@ -4,7 +4,7 @@ ring: adopt
quadrant: tools
---
[RAML](http://raml.org/) (the RESTful API Modelling Language) is a YAML-based API specification language. It's now available in [version 1.0](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#defining-types). The philosophy behind it is to [specify the API before implementation](/methods-and-patterns/api-first-design-approach.html).
[RAML](http://raml.org/) (the RESTful API Modelling Language) is a YAML-based API specification language. It's now available in [version 1.0](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#defining-types). The philosophy behind it is to [specify the API before implementation](/methods-and-patterns/api-first-design-approach/).
If you follow this philosophy, you can design your API and discuss it with your clients and team before implementing a single line of code. API consumers are able to implement against the API before it's really up and running. The [api-console](https://github.com/mulesoft/api-console) provides a beautiful online documentation with "try it" features for your raml definition.

View File

@@ -11,7 +11,7 @@ There are a lot of different resilience patterns and it is also a matter of the
* Do not hide API calls or any other external communication in your application (for example with unnecessary abstraction) - instead make it explicit that an external communication happens - e.g. by using the Facade Pattern. On the one hand, this makes it obvious that a potential slow and error prone communication is going to happen, and it makes it easier to implement error handling.
* Detect errors explicitly: Check the response message format and configure proper timeouts for external communication
* Handle errors in a smart way: Show a nice error message to your customer or, even better, graceful degrade features - e.g. by showing some fallback text
* Use Message-based communication where useful ([Decoupling Infrastructure via Messaging](/methods-and-patterns/decoupling-infrastructure-via-messaging.html))
* Use Message-based communication where useful ([Decoupling Infrastructure via Messaging](/methods-and-patterns/decoupling-infrastructure-via-messaging/))
* Use Circuit Breaker to Isolate errors and allow system to recover
* Use short activation paths in your strategic architecture - so that there is only a minimal set of communications between your services required for certain features or business requests

View File

@@ -14,7 +14,7 @@ Core features of Sass are:
* Extends: CSS properties can be inherited
* Sass files can be split into modules, which leads to smaller files and better file structures
* Operators: Simple math calculations can be applied to CSS properties
* Easily to integrate in nodejs-environments and build tools such as [npm](/tools/npm.html), [Gulp](/tools/gulp.html) and [Grunt](/tools/grunt.html).
* Easily to integrate in nodejs-environments and build tools such as [npm](/tools/npm/), [Gulp](/tools/gulp/) and [Grunt](/tools/grunt/).
Sass has been widely adopted for many years and has evolved to an industry-standard backed by an active community since 2006.

View File

@@ -6,6 +6,6 @@ quadrant: methods-and-patterns
While deploying applications to an environment, the application typically needs to be configured for that specific environment. Typical settings include domain names, database credentials and the location of other dependent services such as cache backends, queues or session storages.
These settings should not be shipped with the build package. Instead, it's the environment - this build is being deployed to - that should expose these values to application. A common way to "inject" these values is by making them available as environment variables or dynamically creating configuration files for the application. You can achieve this pattern without special tools - but this concept of settings injection also works with tools such as [Consul](/tools/consul.html), [kubernetes](/platforms-and-aoe-services/kubernetes.html) (with configMaps and secrets) or [YAD](https://github.com/AOEpeople/YAD).
These settings should not be shipped with the build package. Instead, it's the environment - this build is being deployed to - that should expose these values to application. A common way to "inject" these values is by making them available as environment variables or dynamically creating configuration files for the application. You can achieve this pattern without special tools - but this concept of settings injection also works with tools such as [Consul](/tools/consul/), [kubernetes](/platforms-and-aoe-services/kubernetes/) (with configMaps and secrets) or [YAD](https://github.com/AOEpeople/YAD).
In this manner, the build package can be independent of the environment it's being deployed to - making it easier to follow the "Build once, deploy often" CI/CD principle.

View File

@@ -4,8 +4,8 @@ ring: assess
quadrant: tools
---
[Spring REST Docs](https://projects.spring.io/spring-restdocs/) auto generates [Asciidoctor](http://asciidoctor.org/) snippets with the help of [Spring MVC Test](http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle#spring-mvc-test-framework) or [RestAssured](/tools/rest-assured.html).
[Spring REST Docs](https://projects.spring.io/spring-restdocs/) auto generates [Asciidoctor](http://asciidoctor.org/) snippets with the help of [Spring MVC Test](http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle#spring-mvc-test-framework) or [RestAssured](/tools/rest-assured/).
So you can be sure that your tests are inline with the documentation.
At AOE, we use [Spring REST Docs](https://projects.spring.io/spring-restdocs/) to document our Rest Services and Hal Resources.
We also use it to auto generate [WireMock](/tools/wiremock.html) Stubs, so the consumer of the service can test against the exact API of the service.
We also use it to auto generate [WireMock](/tools/wiremock/) Stubs, so the consumer of the service can test against the exact API of the service.

View File

@@ -10,9 +10,9 @@ Design of distributed applications need to be done wisely. Strategic Domain Driv
Domain driven design is a well-known pattern family and has been established at AOE for quite some time now. Unlike Domain Driven Design, which focuses on the tactical design in an application, strategic domain driven design is an approach that is very helpful for the high-level strategic design of an application and distributed software architecture.
It is a pattern family focused on using and defining Bounded Context and thinking explicitly of the different relationship patterns and the required "translation" of similar "concepts" between the bounded contexts. It is helpful to argue and find a good strategic architecture in alignment with the requirements, the domain and by considering Conway's Law.
A context map and a common conceptional core help to understand and improve the overall strategic picture. Especially with the [Microservice](/methods-and-patterns/microservices.html) approach, it is important to define and connect services following the low coupling - high cohesion principles by idendifying fitting bounded contexts.
A context map and a common conceptional core help to understand and improve the overall strategic picture. Especially with the [Microservice](/methods-and-patterns/microservices/) approach, it is important to define and connect services following the low coupling - high cohesion principles by idendifying fitting bounded contexts.
The following chart gives an overview of possible relationships between bounded contexts:
![strategic-domain-driven-design-relationships](/images/strategic-domain-driven-design-relationships.png)
While we have found that this approach is especially useful in designing distributed systems and applications with [microservices](/methods-and-patterns/microservices.html), we have also extended this approach to provide guidelines for general enterprise architectures.
While we have found that this approach is especially useful in designing distributed systems and applications with [microservices](/methods-and-patterns/microservices/), we have also extended this approach to provide guidelines for general enterprise architectures.

View File

@@ -16,6 +16,6 @@ TypeScript continues to be actively developed by Microsoft and is well-Integrate
The excellent structure and the possibilities for extension make it a good choice to consider for larger JavaScript projects.
Typescript was the choice for [Angular](/languages-and-frameworks/angular.html) and one can assume that it will get more traction with the success of Angular in the future.
Typescript was the choice for [Angular](/languages-and-frameworks/angular/) and one can assume that it will get more traction with the success of Angular in the future.
There are also projects that support Typescript „code execution“ on the server such as [ts-node](https://www.npmjs.com/package/ts-node).

View File

@@ -4,7 +4,7 @@ ring: trial
quadrant: tools
---
[Webpack](https://webpack.js.org/) is a web bundler for JavaScript applications. Instead of writing scripts to build and bundle your app like you would with [Gulp](/tools/gulp.html), you just define what files you want to load into your bundle.
[Webpack](https://webpack.js.org/) is a web bundler for JavaScript applications. Instead of writing scripts to build and bundle your app like you would with [Gulp](/tools/gulp/), you just define what files you want to load into your bundle.
In the following example, we define that JavaScript files should be handled by babel-loader, excluding the files from node_modules. The logic behind the process comes from the [loader](https://webpack.js.org/concepts/loaders/). You can find the right loader in [npm](https://www.npmjs.com/search?q=loader%20webpack&page=1&ranking=optimal).

View File

@@ -10,6 +10,6 @@ At its core, it is a web server that can be prepared to serve canned responses t
It can be used as a library by any JVM application, or run as a standalone process either on the same host as the system under test or a remote server. All of WireMock's features are accessible via its REST (JSON) interface and its Java API. Additionally, the mock server can be configured via JSON files.
At AOE, we use WireMock as a standalone server to mock APIs that are outside our system context to get a stable environment for testing and rapid feedback. Besides the decoupled test and development advantages, the mocked APIs can also be used in contract-based tests. We also use embedded WireMock in functional tests to stub external services. The explicit test of faults are especially helpful in building and testing the [resilience of your application](/methods-and-patterns/resilience-thinking.html).
At AOE, we use WireMock as a standalone server to mock APIs that are outside our system context to get a stable environment for testing and rapid feedback. Besides the decoupled test and development advantages, the mocked APIs can also be used in contract-based tests. We also use embedded WireMock in functional tests to stub external services. The explicit test of faults are especially helpful in building and testing the [resilience of your application](/methods-and-patterns/resilience-thinking/).
Because of the features such as flexible deployment, powerful request matching and record/payback interactions, as well as the fact that the server runs stable in our project environments, we classify WireMock as *trial*.