Owns mapping between users (members) to capabilities and to cloud resources. We call this the context.
- dotnet core 2.2 sdk
- docker
- docker-compose
- bash
The most significant items found in the repository/directory root are:
.
├── Dockerfile
├── README.md
├── add-migration.sh
├── api-contracts/
├── db/
├── docker-compose.yml
├── docs/
├── fake_dependencies/
├── k8s/
├── pipeline.sh
└── src/
Please note: you'd might also find other items in the repository/directory root.
Here is a small description for each of the items:
| Item | Description |
|---|---|
| Dockerfile | Describes how the runtime environment for the actual application should look like. |
| README.md | This readme file |
| add-migration.sh | Util for quickly generating a database migration script that follows default conventions. Run it like this: ./add-migration.sh "<small description of you change here>". |
| api-contracts/ | Directory that contains the current OpenApi contract(s) exposed from the service. |
| db/ | Directory that contains all things related to the database setup e.g. Dockerfile for init migration container, migration script etc. |
| docker-compose.yml | Docker-compose file for bringing all external dependencies up (some in a 'faked-out' version). |
| docs/ | Directory for any documents that take part in documenting the service e.g. domain events. |
| fake_dependencies/ | Directory containing source code for 'faked-out' dependencies (often written in nodejs). |
| k8s/ | Directory containing all Kubernetes manifests used to describe the desired runtime state for the service in Kubernetes. |
| pipeline.sh | The shell script used to implement the continous integration pipeline. The script also generates a docker container image as a deployment artifact. |
| src/ | The main directory for all the source code for the service. |
First restore dependencies by runing the ./pipeline script located in the repository root or by navigating to the ./src folder and run dotnet restore like shown below:
./pipeline.shcd src
dotnet restoreThen the application can be executed by the following (navigate to the ./src folder):
dotnet run --project CapabilityService.WebApi/The application can also be executed by running the bash script watch-run.sh in the folder local-development running the application this way is good for development on your own machine.
The database will initially start as empty. The image is constructed so that files can be added through the command below, and these will be run in date order (at least if you name the file right).
To add a migration, run:
./add-migration.sh create capability tableWill create an empty migration file (e.g. 20181017194326_create_capability_table.sql) in the ./db/migrations folder. The file will be prefixed with YYMMDDHHMMSS.
To bring up a local postgres database with all migration scripts applied against it, set the environment variables in docker-compose.yml as needed (or use defaults), and run:
docker-compose up --buildAfter adding new migrations, run docker-compose down and re-run the above command.
For information about which domain events are published refere to the domain events document.
Information about capabilities is persisted in layers by applying the the decorator pattern to the ICapabilityApplicationService interface.
The layers act in the following order:
-
The CapabilityApplicationService will use the ICapabilityRepository to attach a Capability to the CapabilityServiceDbContext on CreateCapability().
-
The CapabilityOutboxEnabledDecorator will use the db contexts ChangeTracker to find IAggregateDomainEvents and pass them to the Outbox. The outbox will create DomainEventEnvelopes and call the IRepository<DomainEventEnvelope> with the DomainEventEnvelopes which will be added to the db context,
-
CapabilityTransactionalDecorator will:
- Create a new transaction
- Persist all changes made to the CapabilityServiceDbContext with the call of SaveChangesAsync.
- Commit the created transaction
The effect of this is that no change to database will be made if any of the operations the CapabilityApplicationService or CapabilityOutboxEnabledDecorator fails. Meaning you will not get a inconsistent state where changes made to the capability object is persisted but not reflected in a persisted DomainEventEnvelop.