This Glossary represents the ubiquitous language terminology used throughout Solidground project.
This section contains terminology that is specific to the Solidground tool suite. But first ..
|Stakeholder group. Persons that need the social experience. The domain experts that want to see their needs addressed in features and requirements implemented in the solution.
|Stakeholder group. Any person involved in creating and evolving social experiences for the Fediverse. This group has people in many roles, like Developer, Designer, Tester, etc.
|Collection of projects for a particular client.
|A parallel project track that consists of a related set of activities, procedures and tasks that occur on an ongoing basis throughout the solution lifecycle.
|A discreet stage of the solution lifecycle.
Social experience design
The top-level business domain of the Solidground project. Contains all concepts related to the solution design process followed by client and creator to deliver a social experience for stakeholders.
|Artifacts that comprise a social experience being created with the Solidground tool suite.
|Blueprint that is packaged in a single compressed file for download or transfer to other locations.
|The entirety of development practices that are in use by a creator. They include all development processes, tools used, and stakeholders involved.
|Specific part of the development method that involve workflows to help coordinate manual and automated activities.
|Requirements and objectives of stakeholders that must be taken into account during the SX process.
|Pre-defined sequence of recipes and steps in a SX process to provide guidance for particular project stages or disciplines.
|The methodolical approach to SX that comprises all activities that occur during the solution lifecycle.
|Help with the SX process in the form of structured documentation, tool support and automation to perform tasks and workflows according to best-practices. Process guidance is provided by playbooks and recipes.
|A procedure or guideline that outlines process Steps that lead to improvements of the solution blueprint.
|Generate project structure and code from information gathered in a Floorplanner Blueprint design.
|A packaged part of the social experience that can be deployed on Groundwork. Usually it contains the functionality that relates to a discreet bounded context of the domain design.
|Social networking solution created by the Solidground tool suite tailored to stakeholder needs, that can be hosted as service components on the Groundwork platform.
|Social Experience Design
|Acronym SX. Methodical and inclusive development method to creating collaborative social networking solutions that match all stakeholder Needs.
|The final deliverable defined by the blueprint that satisfies the client’s Needs.
|Encompasses all activities of solution design from first inception to phasing out, end of life.
|Any person or group of people directly or indirectly involved in Social Experience Design, whose needs must be taken into account.
|Documented artifact outlining a single manual or automated task, activity or procedure that is included in a recipe. Steps are executable in workflow automation provided by Taskweave Engine.
|Distinct area of the solution that models closely related concepts and activities in a way that assures business processes are always consistent.
|Structured activities that stakeholders perform in their daily work with help of the social experience being designed.
|Diagram of domain concepts and their relationships that helps clarify specific aspects of the domain or a business process.
|Diagram that depicts the identified bounded contexts and their relationships.
|Domain Driven Design
|Acronym DDD. A structural approach to analyse client needs and keep them in focus throughout the entire development lifecycle.
|Method to gradually elaborate domains into event models in a way where the client and stakeholders are deeply involved.
|Event modeling phase where rough UI sketches are added to the event timeline.
|Event modeling phase where brainstormed events are placed in order of occurrence on a timeline.
|Event modeling phase where the creator brings more detail to the diagrams, to help find gaps in the business process and ease transition to implementation of the models.
|The terminology that all stakeholders agree to use consistently when referring to concepts of a particular domain.
|Further refinement by the creator of the event models such that they can be readily implemented per use case into the solution design.
Joyful creation isn’t a domain that is modeled in our tools, but a paradigm of inclusive solution development that has its own terminology. For more background, please visit Social Coding Movement.
|Free Software Development Lifecycle. Comprising all activities and processes that are relevant to creating sustainable Free Software projects. The lifecycle encompasses all activities, from the project’s inception to its end-of-life.
|Moldable Operational System.
|An inclusive approach to Free Software development that focuses on people’s needs and fostering fostering of healthy projects, communities and ecosystems.
|Event Driven Architecture. A type of software architecture where event messages are exchanged between the various components of the architecture, usually over an event bus.
|Free and Open Source Software. This is equivalent to saying ‘Free Software’. Free as in “Freedom”, not “Gratis” and indicated by its license. We recognize approved licenses of Open Source Initiative (OSI) and Free Software Foundation (FSF).
|A mindset that focuses on continual improvement and finding small ways to make things better.
|Concept of Event Sourcing pattern. Code construct that represents the main concept and consistency boundary of a bounded context. The aggregate encapsulates domain logic and only consumes commands and emits domain events. The aggregate forms the domain layer that is independent of service and infrastructure layers by inversion of control.
|Command Query Responsibility Segregation. Architecture pattern that separates write-side, where commands mutate data, from read-side of the architecture, where queries retrieve data.
|Architecture pattern where domain events are used to hydrate the state of aggregates at any moment in time. In an event-sourced solution no data is overwritten as happens in CRUD applications. All state mutations are stored as event in an event store.
|Concept of CQRS pattern. A data model that is optimal to be queried by a user interface. Read models are updated by domain events, and often represent denormalized views of a domain model that avoid database overhead.
|Fediverse Enhancement Process. A process defined by the SocialHub community to specify extensions to the ActivityPub protocol.