Code Monkey home page Code Monkey logo

archetypes's Introduction

archetypesNPM version

Business archetypes logo

License Dependencies' licenses NSP Status Synk Vulnerabilities
StackShare Dependency Status devDependencies Status
Build Status Coverage percentage Codacy quality All Contributors

quote A business archetype is a primordial thing that occurs consistently and universally in business domains and business software systems.

(Arlow & Neustadt, Enterprise patterns and MDA: building better software with archetype patterns and UML, 2006, p. 5)

commonality/archetypes provides universal, rule-based business collaboration APIs for e-commerce and customer relationship management (CRM). commonality/archetypes specifies semantically-rich models of universally recurring business entities, events, and relationships with OpenAPI 2.0.

What are archetypes?

archetypes model how PartiesPeople and Companies—exchange Products and Services with Payments (normally Money or other Locale-based Currencies like gift-cards). The exchanges are recorded from beginning to end as Orders and managed as Customer Relationships (CRM) between buyers and sellers (with PartyRelationships). When necessary, Rules constrain and determine the types of relationships allowed; how products can be packaged; and whether discounts can be applied.

These business archetypes are expressed as models in open, vendor-neutral OpenAPI/Swagger specifications, which provide:

  1. A common vocabulary and operating framework for how PartiesPeople and Companies—exchange goods and services for Money (with Locale-based Currencies), as well as managing these relationships as Customers (CRM).
  2. Executable documentation that articulates these models and how they interact.
  3. Open-source tools that automatically generate microservice "stubs" and client SDKs.

Table of contents

1. Security

commonality/archetypes provide model-driven OpenAPI specifications for pervasive business patterns. Some of these models contain sensitive personal or company data that require access control and privacy safeguards.

None of commonality/archetypes' specifications come with OpenAPI securityDefinitions. Before exposing any data, please apply the principle of least privilege with your own securityDefinitions as appropriate. You must secure how sensitive data are stored and shared.

2. Installation

Open a Terminal and run this command:

npm install --save archetypes

If your team prefers Yarn:

yarn add archetypes

2.1. Generating servers and clients

quote swagger-api/swagger-codegen contains a template-driven engine to generate documentation, API clients and server stubs in different languages by parsing your OpenAPI / Swagger definition.

Cheng, W., & Tam, T. (2011, August 15). swagger-api/swagger-codegen. Retrieved August 27, 2017, from https://github.com/swagger-api/swagger-codegen

Swagger Codegen will generate servers and clients in many different languages and frameworks.

Follow the Installation and Getting Starting instructions to generate and build servers and clients from workstations, CI-services, or Docker containers.

2.2. Editing OpenAPI specs

  1. Go to https://editor.swagger.io/.
  2. Copy the /archetypes/v1/{archetype}/{archetype}.yaml specification of interest.
  3. Paste the *.yaml source into the editor pane.
  4. Select "Generate Server" or "Generate Client" and choose an option.
  5. If successful, you will prompted to download the ZIPped source code.

3. Usage: API HTTP responses

3.1. curl

The simplest way to test against mock objects at http://api.swindle.net/archetypes/v1/parties with curl in a Terminal.

$ curl \
  -X GET "http://api.swindle.net/archetypes/v1/parties/2e908e75-69a9-47e2-83ae-0c3cc52da84c" \
  -H "accept: application/json"

3.2. Swagger-UI

Go to the api.swindle.net Swagger-UI's "About" section and "Explore" the available Swagger Specs.

The following sections summarize all twelve business archetype patterns as they are released.

4. Party API 📦

REST API

quote The Party archetype represents an identifiable, addressable entity that may have a legal status and that normally has autonomous control over (at least some of) its actions.

Arlow, J., & Neustadt, I. (2006). Party archetype pattern. In Enterprise patterns and MDA: building better software with archetype patterns and UML (p. 122). Boston: Addison-Wesley.

4.1. Standards compliance

Standard Contents
OMG Party Management Facility Specification A standard that supports party management.
ISO 3166 Two- and three-letter country codes and country names.
ISO/IEC 5218:2004 Codes for the representation of human sexes.
ITU-T Recommendations Telecommunication numbering plan.

4.2. Resources

Proposal Contents
63 Genders A proposal for describing Gender as a combination of Physical, Personality and Preferential groups.

4.3. OpenAPI 2.0 Specs

Party's Swagger validity YAML (Content-Type: application/x-yaml)

parties/
├── nominative.yaml
├── parties.yaml
└── unique-identifier.yaml

4.4. API and SDK documentation

Business archetype Definition
Organizations Administrative and functional structures
Parties Identifiable, addressable entity that may have a legal status and that normally has autonomous control over (at least some of) its actions.
People Human beings.
Preferences Choices of (or liking for) something, often from a set of possible or offered options.

4.5. Usage example

Retrieve a Party by identifier with JavaScript:

const Party = require("party");

const api = new Party.PartiesApi();

// {String} The universally unique identifier associated with a Party.
const partyIdentifier = "2e908e75-69a9-47e2-83ae-0c3cc52da84c";

const callback = (error, data, response) => {
  if (error) {
    console.error(error);
  } else {
    console.log(
      "API called successfully. Returned data: " + JSON.stringify(data, null, 2)
    );
  }
  console.log(response);
};
api.getByPartyIdentifier(partyIdentifier, callback);

5. Quantity API 📦

REST API

quote The Quantity archetype represents an amount of something measured according to some standard of measurement.

Arlow, J., & Neustadt, I. (2006). Quantity archetype pattern. In Enterprise patterns and MDA: building better software with archetype patterns and UML (p. 400). Boston: Addison-Wesley.

5.1. Standards compliance

StandardContents
SI International System of Units—Bureau International des Poids et Mesures (BIPM).

5.2. OpenAPI 2.0 Specs

Quantity's Swagger validity YAML (Content-Type: application/x-yaml)

quantities/
├── metric.yaml
├── quantities.yaml
├── quantity.yaml
├── rounding-strategy.yaml
├── si-system-of-units.yaml
└── system-of-units.yaml

5.3. API and SDK documentation

JavaScript client SDK (Node.js) client SDK.

5.4. Usage example

Retrieve an SiBaseUnit by identifier with JavaScript:

const Quantity = require("quantity");

const api = new Quantity.SIInternationalSystemOfUnitsApi();

// {String} The name of the unit/metric.
const name = "meter";

const callback = (error, data, response) => {
  if (error) {
    console.error(error);
  } else {
    console.log(
      "API called successfully. Returned data: " + JSON.stringify(data, null, 2)
    );
  }
  console.log(response);
};

api.getBaseUnitByName(name, callback);

6. Money API 📦

REST API

quote The Money archetype represents an amount of a specific Currency that is acceptedIn one or more Locales.

Arlow, J., & Neustadt, I. (2006). Money archetype pattern. In Enterprise patterns and MDA: building better software with archetype patterns and UML (p. 413). Boston: Addison-Wesley.

6.1. Standards compliance

StandardContents
OMG Currency Specification v1.0 A standard to support international currency.
ISO 4217 Three- and two-letter currency codes, currency numbers, and currency names.
ISO 3166 Two-letter country codes and country names.

6.2. OpenAPI 2.0 Specs

Quantity's Swagger validity YAML (Content-Type: application/x-yaml)

money/
├── currency.definition.yaml
├── money.definition.yaml
├── money.yaml
├── payment-card.definition.yaml
├── payment-method.definition.yaml
├── payment.definition.yaml
└── README.md

6.3. API documentation

JavaScript client SDK (Node.js)

6.4. Usage examples

Get all ISO 4217 Currencies with JavaScript (Node.js):

const Money = require("money");

const moneyApi = new Money.CurrencyApi();

const callback = (error, data, response) => {
  if (error) {
    console.error(error);
  } else {
    console.log(
      "API called successfully. Returned data: " + JSON.stringify(data, null, 2)
    );
  }
  console.log(response);
};

moneyApi.getCurrencies(callback);

Retrieve a Currency by its ISO 4217 alphabetic code with JavaScript:

const Money = require("money");

const moneyApi = new Money.CurrencyApi();

// String | An alphabetic code that represents the currency.
const alphabeticCode = "USD";

const callback = (error, data, response) => {
  if (error) {
    console.error(error);
  } else {
    console.log(
      "API called successfully. Returned data: " + JSON.stringify(data, null, 2)
    );
  }
  console.log(response);
};

moneyApi.getCurrencyByAlphabeticCode(alphabeticCode, callback);

7. PartyRelationship API

REST API

quote The PartyRelationship captures the fact that there is a semantic relationship between two Parties in which each Party plays a specific role.

Arlow, J., & Neustadt, I. (2006). Archetype glossary. In Enterprise patterns and MDA: building better software with archetype patterns and UML (p. 160). Boston: Addison-Wesley.

Roadmap

icon-road-milestone-image MVP3: PartyRelationships and Rules

8. Rule API

REST API

quote The Rule archetype represents a constraint on the operation of the software systems of the business—its semantics are defined by a sequence of RuleElements.

Arlow, J., & Neustadt, I. (2006). Archetype glossary. In Enterprise patterns and MDA: building better software with archetype patterns and UML (p. 449). Boston: Addison-Wesley.

Roadmap

icon-road-milestone-image MVP3: PartyRelationships and Rules

9. Customer relationship management (CRM) API

REST API

quote Customer relationship management (CRM) is about actively managing the relationships between your business and your customers, in order to understand and increase customer value, motivation, and loyalty.

Arlow, J., & Neustadt, I. (2006). Customer relationship management archetype pattern. In Enterprise patterns and MDA: building better software with archetype patterns and UML (p. 187). Boston: Addison-Wesley.

Roadmap

icon-road-milestone-image MVP4: Customer relationship management (CRM)

10. Product API

REST API

quote The Product archetype pattern represents a generalized model for products.

Arlow, J., & Neustadt, I. (2006). Product archetype pattern. In Enterprise patterns and MDA: building better software with archetype patterns and UML (p. 207). Boston: Addison-Wesley.

Roadmap

icon-road-milestone-image MVP5: Product

11. Inventory API

REST API

quote The Inventory archetype represents a collection of InventoryEntries held in stock by a business.

Arlow, J., & Neustadt, I. (2006). Inventory archetype pattern. In Enterprise patterns and MDA: building better software with archetype patterns and UML (p. 271). Boston: Addison-Wesley.

Roadmap

icon-road-milestone-image MVP6: Inventory

12. Order API

REST API

quote The Order archetype represents a request by a buyer for a seller to supply some goods or services.

Arlow, J., & Neustadt, I. (2006). Inventory archetype pattern. In Enterprise patterns and MDA: building better software with archetype patterns and UML (p. 271). Boston: Addison-Wesley.

Roadmap

icon-road-milestone-image MVP7: Inventory

13. Product development and delivery

Packaging

PRs Welcome We welcome contributors and pull requests!

Interested in development contributions? Great! Check out our guidelines for Contributing to archetypes for details.

13.1. Built With

StackShare

archetypes requires the following tech-stack to either run, build, test, or deploy:

Dependency Description Version License Type
@babel/core@^7.1.6 Babel compiler core. 7.1.6 MIT dev
all-contributors-cli@^5.4.1 Tool to easily add recognition for new contributors 5.4.1 MIT dev
[email protected] Generate performance statistics for async or sync functions 0.0.6 UNLICENSED dev
babel-jest@^23.6.0 Jest plugin to use babel for transformation. 23.6.0 MIT dev
babel-preset-env@^1.7.0 A Babel preset for each environment. 1.7.0 MIT dev
babelify@^10.0.0 Babel browserify transform 10.0.0 MIT dev
commitplease@^3.2.0 Validates strings as commit messages 3.2.0 MIT dev
coveralls@^3.0.2 takes json-cov output into stdin and POSTs to coveralls.io 3.0.2 BSD-2-Clause dev
eslint@^5.9.0 An AST-based pattern checker for JavaScript. 5.9.0 MIT dev
eslint-config-standard@^12.0.0 JavaScript Standard Style - ESLint Shareable Config 12.0.0 MIT dev
eslint-config-xo-space@^0.20.0 ESLint shareable config for XO with 2-space indent 0.20.0 MIT dev
eslint-plugin-import@^2.14.0 Import with sanity. 2.14.0 MIT dev
eslint-plugin-jest@^22.1.0 Eslint rules for Jest 22.1.0 MIT dev
eslint-plugin-jsdoc@^3.9.1 JSDoc linting rules for ESLint. 3.9.1 BSD-3-Clause dev
eslint-plugin-no-unsafe-innerhtml@^1.0.16 custom ESLint rule to disallows unsafe innerHTML, outerHTML and insertAdjacentHTML 1.0.16 MPL-2.0 dev
eslint-plugin-no-unsanitized@^3.0.2 ESLint rule to disallow unsanitized code 3.0.2 MPL-2.0 dev
eslint-plugin-node@^8.0.0 Additional ESLint's rules for Node.js 8.0.0 MIT dev
eslint-plugin-promise@^4.0.1 Enforce best practices for JavaScript promises 4.0.1 ISC dev
eslint-plugin-scanjs-rules@^0.2.1 ESLint plugin that contains ScanJS rules 0.2.1 MPL-2.0 dev
eslint-plugin-security@^1.4.0 Security rules for eslint 1.4.0 Apache-2.0 dev
eslint-plugin-standard@^4.0.0 ESlint Plugin for the Standard Linter 4.0.0 MIT dev
eslint-plugin-xss@^0.1.9 Validates XSS related issues of mixing HTML and non-HTML content in variables. 0.1.9 ISC dev
jest@^23.6.0 Delightful JavaScript Testing. 23.6.0 MIT dev
jest-cli@^23.6.0 Delightful JavaScript Testing. 23.6.0 MIT dev
jest-config@^23.6.0 23.6.0 MIT dev
markdown-magic@^0.1.25 Automatically update markdown files with content from external sources 0.1.25 MIT dev
markdown-magic-dependency-table@^1.3.2 Generate table of information about dependencies automatically in markdown 1.3.2 MIT dev
markdown-magic-directory-tree@^1.2.3 Print an archy tree for markdown file 1.2.3 MIT dev
[email protected] Add github contributors to markdown file 0.0.3 MIT dev
markdown-magic-package-scripts@^1.2.1 Print list of scripts in package.json with descriptions 1.2.1 MIT dev
markdown-magic-subpackage-list@^1.1.1 Print a list of subpackages for markdown file 1.1.1 MIT dev
markdown-toc@^1.2.0 Generate a markdown TOC (table of contents) with Remarkable. 1.2.0 MIT dev
prettier@^1.15.2 Prettier is an opinionated code formatter 1.15.2 MIT dev
semantic-release@^15.12.... Automated semver compliant package publishing 15.12.2 MIT dev
snyk@^1.110.... snyk library and cli utility 1.110.2 Apache-2.0 dev
sonar-scanner@^3.1.0 Wrap sonar-scanner as a node module 3.1.0 MIT dev
standard-version@^4.4.0 replacement for npm version with automatic CHANGELOG generation 4.4.0 ISC dev
swagger-parser@^6.0.2 Swagger 2.0 and OpenAPI 3.0 parser and validator for Node and browsers 6.0.2 MIT dev
[email protected] schronize a remote directory with a local one, then run a series of preset commands on the server 0.0.2 UNLICENSED dev
travis-deploy-once@^5.0.9 Run a deployment script only once in the Travis test matrix 5.0.9 MIT dev

Keep track of archetypes' tech-stack with these news and RSS feeds.

13.2. Prerequisite

Node.js: commonality/archetypes product development and delivery require Node.js (version 6.x or greater) and its package manager, npm. for build, test, and release tasks.

13.3. Set up a development environment

Here's a brief intro about what a developer must do in order to start developing the project further:

$ git clone https://github.com/commonality/archetypes.git
$ cd archetypes/
$ npm install

13.4. npm-scripts

Software modules often have funky, irrelative names, which is why we prefix custom tasks by their responsibility and purpose.

Prefix Definition
build* Source code distribution tasks.
docs* API documentation and automation tasks.
lint* Code style, standards, and vulnerabilty assessments (as well as fixes, if available).
release Bump the product's semver, update docs, commit, and publish to the npm registry.
security* Security vulnerabilty checks.

The following CLI npm-scripts are available to you (assuming you're human, gentle reader) and CI-services.

Script Description
build:bundle:all npm run build:bundle:money && npm run build:bundle:parties && npm run build:bundle:quantities
build:bundle:money swagger bundle --dereference --outfile ./schemas/v1/money/money.bundle.json ./schemas/v1/money/money.spec.yaml
build:bundle:parties swagger bundle --dereference --outfile ./schemas/v1/parties/parties.bundle.json ./schemas/v1/parties/parties.yaml
build:bundle:quantities swagger bundle --dereference --outfile ./schemas/v1/quantities/quantities.bundle.json ./schemas/v1/quantities/quantities.yaml
docs node generate-docs.js && npm run docs:toc
docs:contributors all-contributors
docs:contributors:add all-contributors add
docs:contributors:generate all-contributors generate
docs:toc ./node_modules/.bin/markdown-toc -i README.md
lint npm run lint:js && npm run lint:swagger:all
lint:js eslint . --fix
lint:md prettier --write README.md
lint:sonar node_modules/sonar-scanner/bin/sonar-scanner
lint:swagger:all npm run lint:swagger:parties
lint:swagger:money swagger validate schemas/v1/money/money.spec.yaml --debug
lint:swagger:parties swagger validate schemas/v1/parties/parties.yaml --debug
lint:swagger:quantities swagger validate schemas/v1/quantities/quantities.yaml --debug
postbump echo $npm_package_version
prepublishOnly npm run docs
preversion npm run docs
security npm run security:nsp:scan && npm run security:snyk:all
security:audit npm run security:audit:scan
security:audit:scan npm audit
security:snyk snyk
security:snyk:all npm run security:snyk:auth && npm run security:snyk:monitor && npm run security:snyk:scan
security:snyk:auth snyk auth $SNYK_TOKEN
security:snyk:monitor snyk monitor --org=commonality
security:snyk:scan snyk test
standard-version standard-version
test jest --config=jest.config.json
posttest npm run security && npm run docs

14. DevSecOps

commonality/archetypes triggers Travis CI builds to execute the ESLint, the Jest test runner, and Node Security Platform (NSP) analysis. Code coverage reports are then sent to Coveralls and SonarCloud.

14.1. Builds

Travis CI

commonality/archetypes uses Travis CI for continuous integration.

For details, please review the .travis.yml build file.

14.2. Tests and quality gates

This repository enforces Swagger quality; Javascript quality; and Javascript unit tests and code coverage.

14.2.1. Swagger validation

Swagger

commonality/archetypes validates Swagger docs with swagger-cli.

swagger-cli validation runs before every test execution:

# These two npm-scripts run lint automatically:
$ npm run pretest

$ npm test

# Only lint the Party OpenAPI specification:
$ npm run lint:swagger:party

# You can also validate your Swagger docs independently with:
$ npm run lint:swagger:all

swagger-api/validator-badges display whether there are syntactic issues with you Swagger/OpenAPI 2.0 document.

14.2.2. Linting

ESLint

commonality/archetypes lints with ESLint and displays real-time results with README badges.

# Code quality analysis runs before every test execution:
$ npm test

# Only validate JavaScript and OpenAPI specs
$ npm run lint

# Only run ESLint:
$ npm run lint:js

14.3.3. Spec (unit test) execution and code coverage

Jest

commonality/archetypes uses jest for BDD spec execution and code coverage analysis. The results are displayed real-time with README badges.

Generate detailed code coverage reports at coverage/lcov-report/index.html and lcov.info and clover.xml files (which you can send to CI test coverage services like Coveralls and [OneSonarQube][one-sonar-url] or SonarCloud):

$ npm test

14.3.4. Deploy/Publish

Conventional Commits with Angular commit conventions

Contributors must follow the Angular commit conventions in order to support automated CHANGELOG, package.json, Git release tags, and semantic version updates.

14.3.4.1. Prerequisites

Once a PR has been approved (and passes all checks), topic branches are are merged into master on GitHub.

  1. On the GitHub PR page, select Squash and Merge.
  2. Add a <title>, <body>, and <footer> that comply with the Conventional Commits Specfication.

14.3.4.2. Publish on npm

When you're ready to release (i.e., publish to npm or a local Node package registry), open a Terminal and follow these steps:

  1. Checkout and pull the latest from master:
$ git checkout master; git pull origin master
  1. Create and document a new semantic version:
# The npm-script "release" executes standard-version
$ npm release

npm release executes an npm-script that will:

  1. Bump the version in package.json

  2. Update CHANGELOG.md (with conventional-changelog)

  3. Commit package.json and CHANGELOG.md

  4. Tag a new release

  5. Push all changes, the new version tag to master, and publish on npm:

$ git push --follow-tags origin master; npm publish

Read more... For standard-version configuration details, read "Cut a Release" on the conventional-changelog/standard-version's README page.

15. Style guides

15.1. JavaScript source code

JavaScript Style Guide

Whenever you run npm test, ESLint will automatically reformat your JavaScript to ensure that all souce code conforms to the JavaScript Standard Style.

Open a Terminal and run any of these commands to ensure your JavaScript source code meets the JavaScript Standard Style:

  • Only lint JavaScript source code (with ESLint):
# Runs eslint . --fix
$ npm run lint:js
  • Lint source and validate OpenAPI specs:
# Lint source and validate OpenAPI specs:
$ npm run pretest
  • Or run all quality gates (including source code linting):
# Or run lint and all other quality gates:
$ npm test

15.2. Color palette

The archetypes documentation uses this color palette:

Color palette

The colors are (from left to right):

  • #CFDBD5: Light Grey
  • #E8EDDF: Platinum
  • #F5CB5C: Stil de Grain Yellow
  • #242423: Raisin Black
  • #333533: Jet

View the palette as PDF, PNG, SCSS, or on coolors.com.

16. Semantic version and CHANGELOG

The latest version of commonality/archetypes is 0.0.0. View the CHANGELOG for details.

17. Contributing to commonality/archetypes

PRs Welcome We welcome contributors and pull requests!

Contributions are community-driven stories with a beginning, a middle, and an end, all told through issues, comments, and pull requests. If you're interested in collaborating, please review the:

17.1. Contribution workflows summarized

We use the Git feature-branch-workflow to accept modifications, where contributors:

  1. Create an issue related to the problem you want to fix (good for traceability and cross-reference)
  2. Label the issue as
    • Type: Defect or
    • Type: Feature
  3. Fork the repository
  4. Create a branch (optionally with the reference to the issue in the name)
  5. Work it
  6. Commit incrementally with readable and detailed commit messages
  7. Submit a pull-request against the master branch of this repository.

We'll take care of tagging your issue with the appropriated labels and answer within a week (hopefully less!) to the problem you encounter.

17.2. Contributors

Thanks goes to these wonderful people (emoji key):


Greg Swindle

💻 🎨 📖 💡 ⚠️

greenkeeper[bot]

⚠️

This project follows the all-contributors specification. Contributions of any kind welcome!

18. Licenses

Apache-2.0 © Greg Swindle.

Third-party licenses: Please see the NOTICE document for 3rd-Party Software information, or select the FOSSA badge below.

FOSSA Status


Code Style Guide for JavaScript Conventional Commits Greenkeeper badge Readme Score StackShare

Graphic art by icons8.


archetypes's People

Contributors

greenkeeper[bot] avatar gregswindle avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

archetypes's Issues

docs(api-specs): revisions

💡 TIP: Select the "Preview" Tab to help read these instructions.

1. Issue type

Type the letter "x" in the "checkbox" the best describe this issue.

  • Feature: I'm requesting an enhancement.
  • Other: I want to discuss something else.

2. User story summary

Describe what you want to accomplish and in what role/capacity, and why it's important to you.
EXAMPLE:
As a Job Applicant,
I want to submit my resume
In order to be considered for a job opening.

As a product maintainer,
I want to use GitHub as much as possible
In order to avoid relying on specs on hosted servers.

3. Acceptance criteria

Replace the examples below with your own imperative, "true/false" statements for the behavior you expect to see, or the behavior that would be true if there were no errors (for defects).

feat(party-relationship): specify the PartyRelationship archetype pattern with OpenAPI 2.0

💡 TIP: Select the "Preview" Tab to help read these instructions.

1. Issue type

Type the letter "x" in the "checkbox" the best describe this issue.

  • Feature: I'm requesting an enhancement.

2. User story summary

Describe what you want to accomplish and in what role/capacity, and why it's important to you.
EXAMPLE:
As a Job Applicant,
I want to submit my resume
In order to be considered for a job opening.

As an API consumer,
I need to define and understand the roles and relationships between Parties
In order to communicate with, market and sell to or by good and services from.

3. Acceptance criteria

Replace the examples below with your own imperative, "true/false" statements for the behavior you expect to see, or the behavior that would be true if there were no errors (for defects).

  • 1. A Party can have zero or more PartyRoles.
  • 2. PartyRoles have PartyRoleIdentifiers that represent their uniqueness.
  • 3. PartyRelationships specify the semantics in which each Party plays a PartyRole.
  • 4. PartyRoles can be associated with PartyRoleTypes, which store common information about a set of PartyRole instances.
  • 5. PartyRelationshipTypes can be associated with PartyRelationships, which store common information about a set of PartyRelationship instances.
  • 6. PartyRelationshipConstraints specify the names of the PartyRoles that may adopt client and supplier (or buyer and seller) sides of a PartyRelationship of a specific PartyRelationshipType.
  • 7. Responsibilities describe activities that a PartyRoleType is expected to perform.
  • 8. AssignedResponsibilities represent Responsibilities assigned to specific PartyRoles; AssignedResponsibilities may (or may not) have from and to dates.
  • 9. PartySummary objects provide "snapshots" of summary contact information about a Party, in relation to a particular context.

feat(money): specify the Money archetype pattern with OpenAPI 2.0

💡 TIP: Select the "Preview" Tab to help read these instructions.

1. Issue type

Type the letter "x" in the "checkbox" the best describe this issue.

  • Feature: I'm requesting an enhancement.

2. User story summary

Describe what you want to accomplish and in what role/capacity, and why it's important to you.

EXAMPLE:
As a Job Applicant,
I want to submit my resume
In order to be considered for a job opening.

As an API consumer,
I need to model Money and Currency by Locale
In order to accomidate future Orders and capture business transactions.

3. Acceptance criteria

Replace the examples below with your own imperative, "true/false" statements for the behavior you expect to see, or the behavior that would be true if there were no errors (for defects).

  • 1. Currency is represented with an OpenAPI 2.0 spec.
  • 2. Money is represented with an OpenAPI 2.0 spec.
  • 3. PaymentMethod is represented with an OpenAPI 2.0 spec.
  • 4. PaymentCard is represented with an OpenAPI 2.0 spec.
  • 5. Payment is represented with an OpenAPI 2.0 spec.

ci(appveyor): build and test on windows

💡 TIP: Select the "Preview" Tab to help read these instructions.

1. Issue type

Type the letter "x" in the "checkbox" the best describe this issue.

  • CIr: I want to discuss something else.

2. User story summary

Describe what you want to accomplish and in what role/capacity, and why it's important to you.

EXAMPLE:
As a Job Applicant,
I want to submit my resume
In order to be considered for a job opening.

As a {role},
I must/need/want/should {do something}
In order to {achieve value}.

3. Acceptance criteria

Replace the examples below with your own imperative, "true/false" statements for the behavior you expect to see, or the behavior that would be true if there were no errors (for defects).

  • 1. Job Applicants receive a confirmation email after they submit their resumes.
  • 2. An Applicant's resume information isn't lost when errors occur.
  • 3. {criterion-three}
  • 4. {criterion-four}

appveyor.yml

install:
  - ps: Install-Product node '7'
  - npm install -g npm --silent --quiet
  - npm install --silent --quiet

platform:
  - x86
  - x64

build: off

test_script:
  - node --version
  - npm --version
  - npm test

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

  • Added the new Node.js version to your .travis.yml
  • The new Node.js version is in-range for the engines in 1 of your package.json files, so that was left alone

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

  • engines was only updated if it defined a single version, not a range.
  • .nvmrc was updated to Node.js 10
  • .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖


FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of lodash is breaking the build 🚨

The dependency lodash was updated from 4.17.10 to 4.17.11.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

lodash is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build failed (Details).

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

feat(party): specify the Party archetype pattern with OpenAPI 2.0 specifications

💡 TIP: Select the "Preview" Tab to help read these instructions.

1. Issue type

Type the letter "x" in the "checkbox" the best describe this issue.

  • Feature: I'm requesting an enhancement.

2. User story summary

Describe what you want to accomplish and in what role/capacity, and why it's important to you.

As an API consumer,
I want to consistently describe essential information about people, organizations, and their preferences,
In order to conduct business unambiguously and clearly.

3. Acceptance criteria

Replace the examples below with your own imperative, "true/false" statements for the behavior you expect to see, or the behavior that would be true if there were no errors (for defects).

The following valid, well-formed OpenAPI 2.0 documents and JSON schemas specify:

  • 1. TheParty represents properties that belong to an identifiable, addressable entity that may have a legal status and that normally has autonomous control over (at least some of) its actions.
  • 1.1. The PartyIdentifier uniquely identifies a Party
  • 1.2. The RegisteredIdentifier represents identifiers assigned by recognized or statutory bodies
  • 1.3. EffectiveDates represent valid "from" and "to" date ranges
  • 2. Address represents contact information by
  • 2.1. ⚠️ GeographicAddress
  • 2.2. ⚠️ TelecomAddress
  • 2.3. ⚠️ EmailAddress
  • 2.4. ⚠️ UrlAddress
  • 2.5. ⚠️ AddressProperties
  • 3. Person represents information about human beings
  • 3.1. IsoSex represents sex
  • 3.2. Gender expresses femininity and masculinity as a continuum of attributes
  • 3.3. Ethnicity represents ethnic and cultural backgrounds
  • 3.4. ⛔️ BodyMetrics provide information about the human body
  • 3.5. PersonName represents peoples' names
  • 4. Organization represents administrative and functional structures
  • 4.1. OrganizationName provides the name of an Organization
  • 4.2 ⚠️ OrganizationUnit represents an Organization that is part of another Organization
  • 4.3 ⚠️ Company represents companies
  • 4.4 CompanyGroup represents a related group of Companies
  • 4.5. CompanyName represents a company name
  • 4.6. ⛔️ Partnerships and SoleProprietors represent their legal counterparts
  • 5. Preference expresses a Party's choice of or liking for something
  • 5.1 PreferenceType provides a range of PreferenceOptions for Parties
  • 6. Expose the APIs with Swagger-UI.
Standard Contents
OMG Party Management Facility Specification A standard that supports party management
ISO 3166 Two- and three-letter country codes and country names
ISO 5218 A representation of human sexes
ITU-T Recommendations Telecommunication numbering plan

4. Implementation notes

4.1. ℹ️ PartyIdentifier

PartyIdentifier has been defined, but it's neither available as an independent service, nor is it explicitly used in an HTTP response body. Instead, the property partyIdentifier is used.

4.2. ⚠️ Addresses

The following Address sub-types have been defined, but they're neither available as independent services, nor are they used in an HTTP response body. I did, however, add an addressType property with an enum for each. Should we also add an address-type input query parameter? Dunno.

⚠️ 2.1. GeographicAddress
⚠️ 2.2. TelecomAddress
⚠️ 2.3. EmailAddress
⚠️ 2.4. UrlAddress

4.3. ⚠️ AddressProperties

AddressProperties has been defined, but it's neither available as an independent service, nor is it explicitly used in an HTTP response body.

4.4. ⛔ BodyMetrics

Omitting this, for now, since I don't have access to ISO 7250-3:2015, "Basic human body measurements for technological design." There's no immediate need for it, anyway.

4.5. ⚠️ OrganizationUnit

OrganizationUnit has been defined, but it's neither available as an independent service, nor is it explicitly used in an HTTP response body. I'm unsure how to express the "Organization within another Organization" relationship. The authors depict this relationship with inheritance, but that smells weird to me.

4.6. ⚠️ CompanyGroup

CompanyGroup has been defined, but it's neither available as an independent service, nor is it explicitly used in an HTTP response body. I suppose it could simply provide an array of its related Companies, but since there's no immediate need for it, I'm not associating an operationId for it.

4.7. ⛔ Partnerships and SoleProprietors

Neither has been defined, nor been made available.

feat(quantity): specify the Quantity archetype pattern with OpenAPI 2.0

User story

As an API consumer,
I want to consistently describe the amount of something measured according to some standard of measurement,
In order to conduct business unambiguously and clearly.

Acceptance criteria

  • 1. Metric represents a standard of measurement for quantities.
  • 2. Unit represents a type of Metrics that is part of a SystemOfUnits
  • 3. SystemOfUnits represents a set of related Units defined by a standard such as the International System of Units (SI)
  • 4. SiBaseUnit provides common properties of SI base units
  • 4.1. Ampere represents an SI unit of electric current
  • 4.2. Candela represents an SI unit of luminous intensity
  • 4.3. Kelvin represents an SI unit of temperature
  • 4.4. Kilogram represents an SI unit of mass
  • 4.5 Meter represents an SI unit of length
  • 4.6. Mole represents an SI unit of amount of substance
  • 4.7. Second represents an SI unit of time
  • 5. DerivedUnit represents a combination of one or more base Units according to a specific equation
  • 5.1. DerivedUnitTerm represents a term, i.e., a single Unit and its power within a DerivedUnit
  • 6. LaborHour represents the amount of work corresponding to one person working for one hour.
  • 7. Quantity specifies an amount that is measured in some Metric and can be used for
  • 7.1. Arithmetic operations
  • 7.2. Comparison operations
  • 7.3. Rounding operations with a
  • 7.3.1. RoundingPolicy that defines the mathematical semantics of the rounding operation, and a
  • 7.3.2. RoundingStrategy that represents the type of rounding to be applied
  • 8. Conversion with
  • 8.1. StandardConversion defines a conversionFactor that can be used to convert a source Quantity to a Quantity in a targetUnit
  • 8.2. UnitConverter represents a conversion process

Compliance with standards

Standard Contents
SI International System of Units (BIPM)

Note

All archetypes have been defined, but not all of them have direct RESTful services that can operate on values.

feat(rules): specify the Rule archetype pattern with OpenAPI 2.0

💡 TIP: Select the "Preview" Tab to help read these instructions.

1. Issue type

Type the letter "x" in the "checkbox" the best describe this issue.

  • Feature: I'm requesting an enhancement.

2. User story summary

Describe what you want to accomplish and in what role/capacity, and why it's important to you.
EXAMPLE:
As a Job Applicant,
I want to submit my resume
In order to be considered for a job opening.

As an API consumer and producer,
I want to explicitly define rules and conditional logic independent of source code and database triggers,
In order to immediate define, execute, review, reuse, and quickly establish personalization and business constraints.

3. Acceptance criteria

Replace the examples below with your own imperative, "true/false" statements for the behavior you expect to see, or the behavior that would be true if there were no errors (for defects).

  • 1. TBD
  • 2. TBD
  • 3. {criterion-three}
  • 4. {criterion-four}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.