iluwatar / iluwatar/java-design-patterns

Functional core, imperative shell pattern

Open
#1,258 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

epic: pattern info: help wanted type: feature
Dominant language
Java
Stars
94.7k
Forks
27.4k
Avg merge
3d 4h
Merged PRs (30d)
10

Description

Description

The Functional Core Imperative Shell (FCIS) design pattern aims to segregate the purely functional part of the code (Functional Core) from the side-effect-laden part (Imperative Shell). This separation enhances testability, maintainability, and robustness by isolating side effects and minimizing their scope.

Main Elements of the Pattern:
  1. Functional Core:

    • Pure functions without side effects.
    • Deterministic outputs based on inputs.
    • Contains the business logic of the application.
    • Facilitates easy unit testing.
  2. Imperative Shell:

    • Encapsulates side effects such as I/O operations, database access, and API calls.
    • Interfaces with the outside world.
    • Manages state changes and interactions.
    • Bridges the Functional Core with the real-world environment.
Implementation Steps:
  1. Identify and extract the business logic into pure functions.
  2. Encapsulate side-effect operations within dedicated modules.
  3. Define clear interfaces between the Functional Core and Imperative Shell.
  4. Write unit tests for the Functional Core functions.
  5. Ensure integration tests cover interactions within the Imperative Shell.

References

Acceptance Criteria

  1. The project codebase should have a clear separation between the Functional Core and the Imperative Shell.
  2. All business logic should reside in pure functions within the Functional Core, with appropriate unit tests.
  3. All side-effect operations should be encapsulated in the Imperative Shell, with integration tests to ensure correct interactions.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. First inspect the repository's existing pattern structure and testing conventions; done would require a clearly separated functional core and imperative shell, with unit tests for pure logic and integration tests for side effects.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
18/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.