work on articles

radar/2017-10-01/adr.md

@@ -4,4 +4,23 @@ ring:       assess
 quadrant:   methods-and-patterns
 
 ---
-TBD
+Architecture Decision Records
+
+Is a lightweight documentation of important architecture decisions taken by the team.
+Without documentation of the architecture and the architecture decisions, new team members can only do two things:
+* either (blindy) accept what they find and see  or
+* (blindy) change things
+
+Both is of course not right.
+
+Therefore we suggest to document the important architecture decisions. We are using a simple tool like https://github.com/npryce/adr-tools and store them in version control.
+In bigger projects with many teams we also establish a regular "architecture board / coi" with regular meetings.
+Often the architecture decision are taken in such meetings.
+
+The main purpose of this documentation is:
+* inform new team members about the previous architecture decisions and its purpose and backgrounds
+* inform the whole team (also all the people who where absent)
+* documentation that can be used to remeber things (e.g. conventions, patterns, etc)
+
+
+

radar/2017-10-01/crc.md

@@ -1,7 +1,38 @@
 ---
-title:      "CRC"
+title:      "CRC Games"
 ring:       assess
 quadrant:   methods-and-patterns
 
 ---
-TBD
+
+Class Responsibility Collaboration Card Games are a method to discuss and align the software design - especially useful for object-oriented software.
+
+A proper software design is one of the most important things to ensure the sucess and the maintainability of your software.
+Especially for iterative development methods where you work on a software task by task, it is important to have designs sessions that also look forward to the next iterations and the conceptional whole.
+
+And for software design to be sucessfull, it is very important that everybody (in the team) has the same understanding of the design and stands behind it.
+
+CRC sessions help to design and align the high level object design and collaboration of your system with the whole team. During such sessions new team members can learn from the experience and explainations of tropers.
+
+This is how we often do this CRC Sessions:
+* Preparation:
+    * Make sure everybody has a high level overview of the software (bounded context / use case overview). Because design should also focus on the long term.
+    * Choose some szenarios (like "customer adds a promoted product to cart and see the discounts..") that you want to discuss in this session
+* Collect candidates for classes:
+    * For the first session it makes sense to search for potential candidates for classes.
+    * Just put them on a whiteboard. Often nouns in szenarios are good candidates.
+    * Put the most promising ones on post its. (You can add more at any time)
+* CRC session:
+    * 1 or 2 people stand up and try to explain the szenario with the help of the classes.
+    * This is much like explaining a sequence diagramm and the cards are put on the table from left to right. During or after this you can discuss design decissions and alternatives with the team.
+    * After this someone else can stand up and present a potential alternative sequence.
+    * Once the team aligned on a version they want to implement, it makes sense that it is repeated by different persons. Beeing exact is very important and avoids the situation where some people have "his" understanding of the model. The model and the collaboration lives in the heads of the people in the team - therefore it is important that everyone understands it the same way.
+* Closing:
+    * We are often not too enthusiatic about adding a list of "collaborators" to the cards, since the sequence explains this very well.
+    * So just take a picture and document the result somewhere, so that you can review the status for the next CRC session.
+    * Maybe some decisions are worth beeing documented in your [Architecture decision records](/methods-and-patterns/adr.html)
+
+
+
+
+

radar/2017-10-01/invision.md

@@ -4,4 +4,10 @@ ring:       trial
 quadrant:   tools
 
 ---
-TBD
+
+Invision is an online tool used to work and collaborate on design and prototypes and to share them between clients and the team.
+
+We use it in many projects now to present prototypes and designs and it helps in understanding the planned user experience.
+Also we use this directly as a reference from the User stories, to help the development teams in understanding and implementing the right frontend and backend functionalities.
+
+

radar/2017-10-01/pact.md

@@ -1,7 +1,17 @@
 ---
 title:      "PACT"
-ring:       assess
+ring:       trial
 quadrant:   tools
 
 ---
-TBD
+
+PACT (http://pact.io/) is a family of frameworks that provide support for *Consumer Driven Contract testing* accross different langauages and frameworks.
+
+Consumer Driven Contract testing is a pattern for testing interfaces/boundaries between services.
+
+It allows "consumers" to run tests against a defined Mock and record the defined interactions (=PACT).
+It puts "providers" in the position, that they can run the PACT tests inside theire Continuous Integration Pipelines, so that the provider knows if he might break any consumers.
+
+This approach makes sense in organisations where teams collaborate more closely (See [Strategic Domain Driven Design](/methods-and-patterns/strategic-domain-driven-design.html) ), e.g. to build [Microservice oriented architectures](/methods-and-patterns/microservices.html)
+
+Consumer Driven Contract Testing and how they can be done with Pact is documented very nicely on the official Pact website: https://docs.pact.io/.

radar/2017-10-01/ports-and-adapters.md

@@ -0,0 +1,34 @@
+---
+title:      "Ports and Adapters"
+ring:       trial
+quadrant:   methods-and-patterns
+
+---
+
+Ports and Adapters is an architecture or layering approach for software design. As with other layering approaches it seperates different concerns in different layers, where dependencies are only allowed to be from the outside to the inside.
+
+We use "ports and adapters" with success for (bigger) applications which contains certain business logic and/or provides several ways to access the services.
+We often use it hand in hands with domain driven design. In comparison with other layering patterns (e.g. layered architecture) it allows to have a true technologie free core (domain) model, because with the concept of "secondary ports" (=interfaces) it inverts the control and allows outer layers to provide adapters (=implementations of the defined interface).
+It also defines clear boundaries for where to put what logic of your application.
+
+You can find more about the details and its origins in famous blog posts like [The Clean Architecture](https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html) or [Hexagonal architecture](http://alistair.cockburn.us/Hexagonal+architecture)
+
+In short here is how we often layer such applications:
+* Domain:
+    * Is the inner layer and contains the technology free domain model
+    * Often using building blocks from domain driven design
+    * It defines primary and secondary ports. (E.g. a secondary port is in "interface" that need to be implemented in the infrastructure layer.)
+* Application:
+    * Contains the Applications API and Services, that are developed around the use cases in the application requirements.
+    * This use cases orchestrate the flow of data to and from the domain
+* Interfaces:
+    * set of adapters that convert data from the 
format most convenient for the 
use cases to the format most convenient for 
some external agency/access
+    * e.g. (Web) Controllers / DTOs for handling forms etc
+* Infrastructure:
+    * This layer is where all the details go. The Web is a detail. 
 The database is a detail.  We keep these things on the 
outside where they can do little harm.
+    * This is where you can use frameworks and tools such as the RDB Mappers etc.
+    * communication details with other external systems (and its DataTransferObjects and Mappers)
+
+This layers belong to every bounded context (modules) inside the application.
+
+So if you are searching for a potential timeless architecture for your critical application? Try to implement a potent technology free domain model in the core layer and use ports and adapters to layer your application.