Difference between revisions of "Separation of concerns"
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[wikipedia:Separation of concerns|Separation of concerns]]([[SoC]]) is a design pattern that reduces information complexity in system design tasks, particularly mentioned in fields as [[urban planning]], [[software architecture]], [[information systems]]. In the realization of [[PKC]], [[SoC]] is being applied to its evolution process. The tool set that drives the implementation of design decisions of [[PKC]], will be distinctively organized to emphasize [[SoC]]. | [[wikipedia:Separation of concerns|Separation of concerns]]([[SoC]]) is a design pattern that reduces information complexity in system design tasks, particularly mentioned in fields as [[urban planning]], [[software architecture]], [[information systems]]. In the realization of [[PKC]], [[SoC]] is being applied to its evolution process. The tool set that drives the implementation of design decisions of [[PKC]], will be distinctively organized to emphasize [[SoC]]. | ||
=SoC applied in [[PKC]]= | |||
To help minimize the dependencies of your personal knowledge repository from implementation technologies, [[PKC]] uses the [[universal data abstraction]], [[hyperlink]], to represent information of any type, and define the [[hyperlink-centric]] data encoding, storage, retrieval, and manipulation, in pure abstraction, based on properties that associates with [[hyperlink]] or [[key-value pair]] only. Then, given the abstract specification of the needs to encode, store, retrieve, and manipulate these [[hyperlink]]s, then, we can find appropriate technologies to conduct these tasks. | |||
==Implementation in [[Kubernetes]]== | |||
In year 2021, when the world is infested with [[Kubernetes]]-managed [[microservices]], [[PKC]] is going to be managed by [[Kubernetes]] as a reference implementation. Due to the field-tested vocabulary of [[Kubernetes]], it has a great set of terminology naturally defined for data governance, which coincide with [[PKC]]'s main design concerns. Therefore, the vocabulary of [[PKC]] will be closely mapped to[[Kubernetes]]'s vocabulary, and documented in a specific namespace, called <code>PKC:</code>. When they are conflicting definitions or terms, we will also denote the differences of these terms in a style that matches MediaWiki's common practice, for example, when certain terms are applied to different domains, we will write the term in the following format: [[Term to be defined (domain of application)|<code>Term to be defined (domain of application)</code>]], such as [[wikipedia:Python (programming language)|<code>Python (programming language)</code>]]. | |||
==The strategic choice of mapping abstract vocabulary to Kerbernetes' vocabulary== | |||
The main reason for choosing Kubernetes as a reference vocabulary, is to help users of [[PKC]] to navigate the complex web of data dependencies in a finite, yet highly automated functionalities of [[Kubernetes]]. It maybe said that [[Kubernetes]] is a kind of tool, dedicated to implement [[separation of concerns]], using nothing by [[key-value pair]]s, which is denoted in [[yaml]] files. | |||
Latest revision as of 10:06, 5 August 2021
Separation of concerns(SoC) is a design pattern that reduces information complexity in system design tasks, particularly mentioned in fields as urban planning, software architecture, information systems. In the realization of PKC, SoC is being applied to its evolution process. The tool set that drives the implementation of design decisions of PKC, will be distinctively organized to emphasize SoC.
SoC applied in PKC
To help minimize the dependencies of your personal knowledge repository from implementation technologies, PKC uses the universal data abstraction, hyperlink, to represent information of any type, and define the hyperlink-centric data encoding, storage, retrieval, and manipulation, in pure abstraction, based on properties that associates with hyperlink or key-value pair only. Then, given the abstract specification of the needs to encode, store, retrieve, and manipulate these hyperlinks, then, we can find appropriate technologies to conduct these tasks.
Implementation in Kubernetes
In year 2021, when the world is infested with Kubernetes-managed microservices, PKC is going to be managed by Kubernetes as a reference implementation. Due to the field-tested vocabulary of Kubernetes, it has a great set of terminology naturally defined for data governance, which coincide with PKC's main design concerns. Therefore, the vocabulary of PKC will be closely mapped toKubernetes's vocabulary, and documented in a specific namespace, called PKC:. When they are conflicting definitions or terms, we will also denote the differences of these terms in a style that matches MediaWiki's common practice, for example, when certain terms are applied to different domains, we will write the term in the following format: Term to be defined (domain of application), such as Python (programming language).
The strategic choice of mapping abstract vocabulary to Kerbernetes' vocabulary
The main reason for choosing Kubernetes as a reference vocabulary, is to help users of PKC to navigate the complex web of data dependencies in a finite, yet highly automated functionalities of Kubernetes. It maybe said that Kubernetes is a kind of tool, dedicated to implement separation of concerns, using nothing by key-value pairs, which is denoted in yaml files.