prototype of the Archivist archetype for the Personify framework
Want to see pretty graphs? Log in now!
npm install archivist
|16||downloads in the last week|
|16||downloads in the last month|
|Last Published By|
|Version||1.0.0 last updated 2 years ago|
An initial prototype for the Archivist archetype of the Personify reference model. An archetype is a meta-level pattern encountered in many different applications. Archetypes provide general functionality usually required in various contexts.
For example, applications often store data in databases. Traditionally, this meant Object-Relational Mapping (ORM). Such applications would often use an Active Record (e.g. Ruby on Rails) or a Data Mapper (e.g. Java Hibernate) to manage data persistence to long-term storage.
Personify manifests this as the Archivist archetype.
Like an archivist (a historian) in a castle, the Archivist archtype personifies the responsibility of storing information into long term storage.
An Archivist are responsible for knowing- where to store things (A StorageLocation)
- what to store (An Archive) - how to store it (An ArchivingStrategy)
An Archivist provides these basic services:- Create(data) returns an Archive with an id that wraps the data - Read(id) returns the Archive with the specified id, or an empty Archive if none found - Update(id, newData) returns the updated Archive if newData validates. May throw a ValidationError if it does not - Delete(id) returns the removed Archive
A particular type of Archivist, for example a MongoDBArchivist, would extend the Archivist archetype through an application of the Decorator pattern and explicitly devise its own StorageLocation, Archives, and ArchivingStrategies by extending the base interfaces and providing their own implemenations.
Source Layout and contents
The directory content of Archivist follows rzr style, adhering to the principles of Domain Driven Design by defining a Bounded Context called domain/ by convention. The domain has separate modules, though it is a rzr guiding principle that blades (plugin components) be as minimalistic as possible. Hence, the Archivist has one module, archivist/.
Each module has an Aggregate Root, conventionally named for the Module (in this case, Archivist.coffee). The Module contains the standard DDD components of Models and Services. Factories and Repositories are option, though the beta applications in Personify have delegated those responsiblities to other Agents (the Archivist is the Repository handler). The Aggregate root exposes the agents the module provides for external interface. Modules in rzr style are Agents, though they may not always be very smart.
More on Agent Implementation
A dumb Agent may function much like an ideal Front Controller in a traditional Model-View-Controller application, forming an API for the services it provides and delegating requests appropriately.
More intelligent agents may use reasoning engines to examine their current context, ensure the safety and validity of the information they have been provided, and align their actions with their models of the world, their beliefs, and their goals.
Personify Agents are entities with stated contracts, similar to Design By Contract. These contracts are written in a Domain Specific Language for contract generation. These contracts outline their Beliefs, Capabilities, and Commitments. Beliefs expressed in the contracts become manifested in the Domain Model, which is updated and used by the Agent's Brain to update according to change in context and carry out actions.
The Archivist archetype is intentionally naive. Domain specific agents should decorate it with context-specific intelligence.
The Archivist archetype strives to be Simple and Easy, following Rich Hickey's definition. It provides simple CRUD to the external world.
Archivists really should not do more than this. Following the Single Responsibility Principle, they are intended to be specialized agents within an organization, requested by others to store data.
If feature functionality beyond the simple use case "Store Information X in Place Y by doing Z" starts to creep into your implementation, YOAR DOING IT WRONG. Refactor that logic elsewhere.