pms-domain-model: pms-domain-model

[ ai, apache, library ] [ Propose Tags ] [ Report a vulnerability ]

README.md


[Skip to Readme]

Modules

  • PMS
    • Domain
      • Model
        • DM
          • PMS.Domain.Model.DM.Constant
          • PMS.Domain.Model.DM.TH
          • PMS.Domain.Model.DM.Type
        • DS
          • PMS.Domain.Model.DS.Utility

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

  • No Candidates
Versions [RSS] 0.0.1.0, 0.0.1.1
Change log CHANGELOG.md
Dependencies aeson, base (>=4.21.0.0 && <4.22), bytestring, data-default, fast-logger, filepath, lens, monad-logger, mtl, safe-exceptions, stm, text, transformers [details]
License Apache-2.0
Copyright 2025-2026 phoityne.hs@gmail.com
Author phoityne.hs@gmail.com
Maintainer phoityne.hs@gmail.com
Category AI
Home page https://github.com/phoityne/pms-domain-model
Bug tracker https://github.com/phoityne/pms-domain-model/issues
Uploaded by phoityne_hs at 2025-06-03T11:14:55Z
Distributions
Reverse Dependencies 3 direct, 0 indirect [details]
Downloads 7 total (7 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs not available [build log]
All reported builds failed as of 2025-06-03 [all 2 reports]

Readme for pms-domain-model-0.0.1.1

[back to package description]

pms-domain-model

Positioning of pms-domain-model in the pty-mcp-server Project

pms-domain-model is a core internal package within the pty-mcp-server project. It defines the essential domain types — such as value objects, identifiers, parameters, and domain-specific data structures — that precisely capture the semantics of the problem domain.

The package does not contain any implementation of behavior, business logic, or state management. Instead, it is strictly responsible for representing the domain context as purely declarative data. This clear separation ensures that domain semantics are explicitly encoded and remain stable, independent of application workflows or infrastructure concerns.

The domain logic itself — that is, the implementation of business rules, behaviors, and state transitions — is separated and encapsulated in the domain-service layer. This design enables a clean architectural separation where the pms-domain-model defines the core domain vocabulary and invariants, while the domain-service implements the operations and business processes that act upon this data.

In this architectural style, inspired by principles from Onion Architecture, Clean Architecture, and similar approaches, the domain model forms the innermost core and defines the ubiquitous language and invariants of the business domain. Application logic, state transitions, and side effects are implemented in outer layers, such as the domain service and application layers, which rely on these core types.


Insights into Domain Modeling in Haskell from This Development

During the development of pty-mcp-server, important insights were gained into how Haskell’s strong and expressive type system influences the conception and implementation of domain models:

  • The domain model is naturally represented as a set of data types that encode domain semantics precisely, without embedding behavior or mutable state.

  • The notion of domain context in Haskell goes beyond just data types. It includes phantom types, newtypes, and tagged constructors to express domain distinctions and constraints in a type-safe manner.

  • Application context — including configuration, resources, logging, and effect management — is captured through monad stacks and typeclass-based capabilities, enabling composable and testable implementations of operational concerns.

This results in a distinct architectural pattern where domain data (the core model) is strictly separated from behavior and side effects, while still fully driving the correctness of program construction.

pms-domain-model thus acts as the semantic center of the system. Any computation in the application or domain service layers must align with and respect the data types and constraints defined here.

This approach effectively adapts architectural concepts inspired by Onion Architecture, Clean Architecture, and similar methodologies to Haskell. It leverages language-specific features such as strong static typing and monadic effects to maintain purity, testability, and maintainability.

By treating the context (implemented as monad stacks) as the bridge between domain data and application logic, this design achieves a clean separation of concerns and supports practical software development workflows in Haskell.


Summary

pms-domain-model represents a Haskell-specific embodiment of architectural concepts inspired by Clean/Onion Architecture and similar approaches:
a data-centric, behavior-agnostic core that precisely encodes the problem domain and provides the foundation for the system’s semantics, enabling robust, maintainable, and scalable application development.

Adopting and adapting these architectural principles in Haskell aligns well with the language’s characteristics. Haskell’s strong static typing and pure functional nature naturally facilitate clear separation of concerns and enforcement of domain invariants at the type level. This alignment enhances testability, maintainability, and expressiveness of the domain model, making the approach both feasible and beneficial.


Package Structure

Package Structure


Module Structure

Package Structure