AJR/TechRadarAJR
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

add some crosslinks

Browse Source
This commit is contained in:
Daniel Pötzinger
2017-04-06 23:49:54 +02:00
parent f48f142ebc
commit 7305634cb8
3 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
radar/2017-03-01/raml.md
View File

@@ -5,7 +5,7 @@ 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.
[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).
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.

2
radar/2017-03-01/settings-injection.md
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) 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.html), [kubernetes](/platforms-and-aoe-services/kubernetes.html) (with configMaps and secrets) or [YAD](https://github.com/AOEpeople/YAD).
In this manner, the build package can be independent from the environment it's being deployed to - making it easier to follow the "Build once, deploy often" CI/CD principle.

4
radar/2017-03-01/strategic-domain-driven-design.md
View File

@@ -10,10 +10,10 @@ 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 familiy 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 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.html) 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](/assets/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, we have also extended this approach to provide guidlines 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.html), we have also extended this approach to provide guidlines for general enterprise architectures.