New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
meta.domainId -> meta.source.domainId #36
meta.domainId -> meta.source.domainId #36
Conversation
As discussed in other PR, will leave this hanging until we've moved other repositories into this one. |
Linking to issue #35. |
If you rebase to topic-drop3 you'll be able to include example and schema changes in this PR. |
* meta.domainId -> meta.source.domainId * make source a required field * extended description for domainId Signed-off-by: Andrey Devyatkin <andrey.a.devyatkin@gmail.com>
Signed-off-by: Andrey Devyatkin <andrey.a.devyatkin@gmail.com>
Signed-off-by: Andrey Devyatkin <andrey.a.devyatkin@gmail.com>
__Format:__ Free text | ||
__Required:__ Yes | ||
__Description:__ Identifies the domain that produced an event. A domain is an infrastructure topological concept, which may or may not corresponds to an organization or product structures. A good example would be Java packages notation, ex. com.mycompany.product.component or mycompany.site.division. Also, keep in mind, that division names, as well as product/component names, tends to change. That is why it might be a good idea to pick coded names that do not directly reflect current naming in the organization. Think of flower names as names for sites or simply site1, site2, site3 instead of Sweden, Denmark, Norway. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still not convinced about this. My recommendation would be something along the lines of "Also, keep in mind that all names are more or less prone to change. Particularly, it is recommended to avoid organizational names or site names, as organizations tend to be volatile and development is easily relocated. Relatively speaking, product and component names tend to be more stable and are therefore encouraged, while code names may be an option. You need to decide what is the most sensible option in your case."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated accordingly in the latest commit
Signed-off-by: Andrey Devyatkin <andrey.a.devyatkin@gmail.com>
👍 |
1 similar comment
👍 |
Signed-off-by: Andrey Devyatkin andrey.a.devyatkin@gmail.com