This repository illustrates the use of Contextive in an environment where multiple repositories are part of the same bounded context
and need access to the same set of definitions.
In this pattern, the definitions are contained within a common
repository - e.g. https://github.com/dev-cycles/contextive-demo-go-common
Native package management and distribution techniques are leveraged to ensure the definitions are available to your IDE while working on the service repo.
- Add your definitions file to a 'shared' repository for the bounded context - something which stores any common context-wide code, such as entities, contexts, constants etc.
- In this demo, it's contextive-demo-go-common
- Ensure the definitions file is included in the distributed package.
- For
go
this is as simple as having it in the repository
- For
- Depend on the common package using standard package techniques.
- In this case
go get
. - See go.mod for the reference to contextive-demo-go-common
- In this case
- Set the
contextive.path
setting in the service repository as a workspace setting and leverage a shell command to locate thecontextive-demo-go-common
package:$(go list -m -f '{{.Dir}}' github.com/dev-cycles/contextive-demo-go-common)/.contextive/definitions.yml
- See ./.vscode/settings.json for an example
When you clone this current repository, after running go build
or go test
, the dependencies will be downloaded and the definitions defined in contextive-demo-go-common should be available in the UI.
-
When the definitions are updated in the
common
package, it will need republishing, and the services will need to update to the latest version of the package to pick up the updated definitions. -
Contextive currently only activates in VSCode on the presence of a
.contextive
folder in the repo. To that end, a dummyREADME.md
is included in that folder to ensure Contextive activates.