Platform Contributor Guide
[Legacy v3] Platform
[Legacy v3] Platform
  • 👋[Legacy v3] Welcome | README
  • Contributing | Getting Involved
    • Specific tasks needed for COVID19-support
    • Add code to Ushahidi
    • Encouraging contribution from non-developers
  • Frequently Asked Questions
  • Join the Ushahidi community
  • Contributors ✨
  • 🛣️ The Ushahidi Platform Roadmap
    • V2-V3+ Migration tool
  • Privacy and security best practices
    • Security as a user
    • Security for deployment admins
    • Security for deployment hosts
  • Development & Code
    • Development: Overview
    • How to get the source code
    • Setup Guides
      • Installing for production environments
      • Development environment with XAMPP
      • Development environment setup with Vagrant
      • [Client] Setting up the Platform Client for development
        • Migration from AngularJS
      • Setting up the Pattern Library for development
      • [API & Client] Bundled release install
    • Add code to Ushahidi
    • Development process
    • Coding Standards
    • Track and submit issues in Github
    • Upgrading Ushahidi
      • Upgrading to latest release
      • Upgrading from V3.x.x to V4.x.x
    • ⚙️ Installation Helper‌
  • Tech Stack
    • API Documentation
    • Third party app development
      • Web hooks
    • Database | Tables overview
    • Database | Database Schema Diagram
    • Database | Table details
    • 📐Architecture
    • Use case internals
  • QA & Testing
    • The QA process
    • How to run QA tests
    • Defect Management
    • How to write QA test scripts
    • Hotfixes
  • Front-end development
    • Changing UI styles: introduction to the pattern library
      • File-structure
      • Installing new packages
      • How to Apply to the Platform
      • Using the changed styles in platform-client
      • Syntax and Formatting
      • Grid, Breakpoints, & Media Queries
      • Variables
      • Mixins
      • Helpers
      • Icons
      • Create a New Component from Scratch
      • Read Direction
  • Design
    • 🎨Design: overview
    • 'Best practice' design
    • Ushahidi Platform 'Sticker Sheet'
    • User testing process
    • User testing script examples
    • Synthesising user testing results examples
      • Synthesis example 1
      • Synthesis example 2
      • Synthesis example 3
      • Synthesis recommendations example 1
      • Synthesis recommendations example 2
    • Open Source Design
  • Documentation
    • Documentation
    • Contributing docs via GitHub
  • Translation
    • Localization and Translation
  • The Ushahidi Platform Facebook bot
    • The Facebook bot
      • Installing the bot
      • The bot script
  • Hackathon and events
    • Installathon, May 2019
      • Welcome to the hackathon!
    • Write/Speak/Code 2019
    • Open Design: Bangalore
    • Open Design: Taipei
    • 📑Google season of docs
    • 💻Google Summer of Code
      • GSoC 2024
  • Enhancement Proposals
    • Exchange Format
    • Importing data from previous versions
Powered by GitBook
On this page
  • Use Case Internals
  • What is a use case?
  • Anatomy of a Use Case (in platform)
  • CRUDS use cases
  1. Tech Stack

Use case internals

Use Case Internals

What is a use case?

Part of Hexagonal Architecture is the concept of the Application Boundary. This boundary separates our application as a whole from everything else (both framework and communication with the outside world).

A Use Case (sometimes called a Command) is an explicitly defined way in which an application can be used.

We define how the outside world can communicate with our application by creating "Use Cases". These essentially are classes which name actions that can be taken. For example, our CreatePostUsecase defines that our application can create a post.

Defining Use Cases has some useful side-affects. For example, we clearly and explicitly can see how our application "wants" to be interacted with. We can plan use cases ahead of time, or add them as needed, but use cases should capture the operations which can happen within our application.

Aside: Platform uses some generic CRUDS usecases. These aren't tied to a specific Domain Model (Entity) ie. a Post but rather have the entity and repo injected into them. This makes Use Cases significantly less well defined. A developer can no longer glance at the Use Case directory and see what actions are available. This might be something we can improve in future

Anatomy of a Use Case (in platform)

Use Cases in platform all follow a high level interface. In short they all have a interact() method.

interface Usecase
{
    /**
     * @return Array
     */
    public function interact();
}

To enable building of some generic use cases they also have isSearch and isWrite methods.

interface Usecase
{
    /**
     * Will this usecase write any data?
     *
     * @return Boolean
     */
    public function isWrite();

    /**
     * Will this usecase search for data?
     *
     * @return Boolean
     */
    public function isSearch();

    /**
     * @return Array
     */
    public function interact();
}

The actual parameters for each UseCase are injected through setter methods, commonly: setPayload(), setIdentifiers and setFilters.

CRUDS use cases

Most of our use cases follow 5 high level patterns for Create, Read, Update, Delete and Search (CRUDS)

Create

Read

Update

Delete

Search

PreviousArchitectureNextThe QA process

create
collaborators
read
update
delete
search
Create Usecase
Create Usecase - Collaborators
Read Usecase
Update Usecase
Delete Usecase
Search Usecase