-
Notifications
You must be signed in to change notification settings - Fork 88
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
devon4j documentation correction #315
Conversation
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.
@dixyushi thanks for fixing all these typos and missing commas. Seems like some native speaker did some constructive review here. Awesome 👍
* This will cause incompatibilities (and compile errors) in the copied service. Therefore you need to fix that service implementation to map from the old API to the new API and behavior. In some cases this may be easy (e.g. mapping `x.y.z.v1.FooTo` to `x.y.z.FooTo` using link:guide-beanmapping.asciidoc[bean-mapping] with some custom mapping for the incompatible change), in other cases this can get very complex. Be aware of this complexity from the start before you make your decision about service versioning. | ||
* As far as possible this mapping should be done in the service-layer, to not pollute your business code in the core-layer with versioning-aspects. If there is no way to handle it in the service layer, e.g. you need some data from the persistence-layer, implement the "mapping" in the core-layer then, but don't forget to remove this code, when removing the old service version. | ||
* Finally ensure that both the old service behaves as before as well as the new service works as planned. | ||
* This will cause incompatibilities (and compile errors) in the copied service. Therefore, you need to fix that service implementation to map from the old API to the new API and behavior. In some casesc, this may be easy (e.g. mapping `x.y.z.v1.FooTo` to `x.y.z.FooTo` using link:guide-beanmapping.asciidoc[bean-mapping] with some custom mapping for the incompatible changes), in other cases this can get very complex. Be aware of this complexity from the start before you make your decision about service versioning. |
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.
cases
seemed correct here. I guess casesc
was a typo when you wanted to add a comma.
@@ -3,7 +3,7 @@ toc::[] | |||
:idprefix: | |||
:idseparator: - | |||
|
|||
There are many different views on what is summarized by the term _architecture_. First we introduce the xref:key-principles[key principles] and xref:architecture-principles[architecture principles] of devonfw. Then we go into details of the the xref:application-architecture[architecture of an application]. | |||
There are many different views that are summarized by the term _architecture_. First, we will introduce the xref:key-principles[key principles] and xref:architecture-principles[architecture principles] of devonfw. Then, we will go into details of the the xref:application-architecture[architecture of an application]. |
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.
IMHO the original idea was to say that architecture is a common term but different people have different understandings and views on this. With the change it now IMHO says that architecture summarizes different views (like the view of a developer, operator, business-analyst?) in one term.
No description provided.