<Additional information about your API call. Try to use verbs that match both request type (fetching vs modifying) and plurality (one vs multiple).>
-
URL
<The URL Structure (path only, no root url)>
-
Method:
André Amorim andrzj
andrzj
/ docker-compose.yml
Last active
March 1, 2020 01:47
— forked from pantsel/docker-compose.yml
example docker-compose.yml for kong, postgres and konga
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| version: "2.1" | |
| networks: | |
| kong-net: | |
| driver: bridge | |
| services: | |
| ####################################### | |
| # Postgres: The database used by Kong |
andrzj
/ CQRS.md
Created
October 16, 2024 23:15
— forked from meigwilym/CQRS.md
CQRS, Task Based UIs, Event Sourcing agh!
Posted by gregyoung on February 16, 2010
Many people have been getting confused over what CQRS is. They look at CQRS as being an architecture; it is not. CQRS is a very simple pattern that enables many opportunities for architecture that may otherwise not exist. CQRS is not eventual consistency, it is not eventing, it is not messaging, it is not having separated models for reading and writing, nor is it using event sourcing. I want to take a few paragraphs to describe first exactly what CQRS is and then how it relates to other patterns.
Starting with CQRS, CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation, a command is any method that mutates state and a query is any method that returns a value).
I see a lot of posts about "getting stuck", "burning through tokens" and "going around in circles" etc. To prevent this you need to add tests and get them to pass. Aim at 60% test coverage. Otherwise when your app or program because more complicated, bringing in a new change will break an already working feature. The app does not know what to consider when making changes as it doesn't have the context from all of your previous conversations. Whereas if you add tests, they will fail and when this occurs and the app will understand the purpose of the test, and that you need to maintain that functionality. It will add a bit of time in the beginning but save you from a world of hurt later on.
OlderNewer