Skip to content
TDP Backend Docs

Feature Design

A feature in this context is considered as an atomic functionality that needs to be exposed as an API in a service. In this article a typical feature design and implementation is presented, with some variations and considerations.

An example of a feature is the creation of a project in the Tdp.Projects service, and it will be used as a typical feature to explain the different parts of the feature implementation.

Feature Design

When a feature is requested, it is usually presented as a user story or a requirement.

E.g.:

As a platform administrator, I want to create a project in the system for a new client.

The project creation should ask for:

  • a display name to visually identify the project in the UI.
  • a unique code in the context of the platform.
    • The code uniqueness should be validated before sending the request to the service, but the service should also validate it.

When the project is finally created:

  • The project should be left in a draft state.
  • Any process that could be derived from this creation should be triggered.

The feature could be accompanied by a UI sketch to help the developer understand the requirements:

Feature sketch example

Feature Implementation

The feature implementation is divided into the following parts:

  1. Internal API: The service responsible for implementing the feature MUST decide the protocol based on the corresponding Architecture Decision Records (ADR). It can typically be a REST API, but also could be a gRPC API or a message-based API. This protocol will be used to communicate with the service within the system boundaries, and not with the external clients.
  2. Transport: Once the request is received, the API MUST use a transport mechanism to send any query or command to the business layer. This transport mechanism could be a message bus, a mediator, or a simple method call to a business service.
  3. Business Layer: The business layer is responsible for handling the business logic of the feature. It should be the only place where the business rules are implemented.
  4. Data Access Layer: The data access layer is responsible for handling the data persistence. It should be the only place where the data access logic is implemented.
  5. External API: The gateway is a library that implements a predefined protocol to expose the parts of a feature that are meant to be consumed by external clients.
  6. User Interface: The user interface is the part of the feature that is meant to be consumed by the end-user. It could be a web page, a mobile app, or a desktop application.
  7. Client SDK: The client SDK is a library that implements the Internal API protocol to allow the Gateway and other internal services to communicate with the service, within the system boundaries.
  8. Persistent Storage: The persistent storage is the database where the data is stored. It could be a SQL database, a NoSQL database, or any other kind of storage.

Feature implementation diagram