Bonyan.Layer.Domain 1.1.9

There is a newer version of this package available.
See the version list below for details.
dotnet add package Bonyan.Layer.Domain --version 1.1.9                
NuGet\Install-Package Bonyan.Layer.Domain -Version 1.1.9                
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Bonyan.Layer.Domain" Version="1.1.9" />                
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add Bonyan.Layer.Domain --version 1.1.9                
#r "nuget: Bonyan.Layer.Domain, 1.1.9"                
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install Bonyan.Layer.Domain as a Cake Addin
#addin nuget:?package=Bonyan.Layer.Domain&version=1.1.9

// Install Bonyan.Layer.Domain as a Cake Tool
#tool nuget:?package=Bonyan.Layer.Domain&version=1.1.9                

Bonyan Modular Monolithic Library

Purpose

The Bonyan Library is designed to facilitate the development of modular monolithic architectures in .NET Core projects. It provides a foundation for creating systems that are both easy to maintain and scalable, allowing developers to enjoy the benefits of modularity without the complexity of distributed microservices.

The primary purpose of this library is to solve the common challenges developers face when trying to create a monolithic codebase that remains modular, maintainable, and adaptable as the project grows.

Getting Started

For a detailed guide on getting started with the Bonyan Library, including installation and initial configuration steps, please visit the Getting Started page.

What is a Modular Project?

A modular project is an approach to building software where the system is divided into distinct, loosely-coupled units called modules. Each module encapsulates a specific set of functionalities, with clear boundaries and dependencies. This kind of structure helps improve separation of concerns, making the codebase easier to navigate and maintain.

In a modular monolithic architecture, all modules are part of the same deployable unit (the monolith). Despite being part of a single application, each module is designed to be independent and reusable, promoting a clean separation of responsibilities.

Challenges with Traditional Monolithic Architectures

Traditional monolithic architectures often start simple, but as the codebase grows, they become difficult to manage due to tightly coupled components. Key challenges include:

  • Complexity Increases: As features are added, components become tightly coupled, making it difficult to modify one part of the system without affecting others.
  • Maintenance Issues: It becomes harder to maintain or refactor the system as developers need to understand the full complexity of the entire application.
  • Scaling Limitations: Scaling traditionally involves scaling the entire application rather than scaling specific functionalities, leading to resource inefficiencies.

These challenges make monolithic applications cumbersome and brittle, especially when they grow beyond a certain point.

How Does Bonyan Library Solve These Problems?

The Bonyan Library addresses these challenges by providing a set of tools and frameworks that enable developers to structure their monolithic applications in a modular way. This approach allows developers to retain the simplicity of a monolith while introducing a modular structure that makes the system scalable and maintainable. Here are the main problems it solves:

  1. Tightly Coupled Components: By introducing modular boundaries, each component (or module) within the monolith is developed independently. The modules are well-encapsulated, and interaction between modules is managed through clearly defined interfaces. This significantly reduces the interdependencies between different parts of the system.

  2. Maintenance Overhead: The library promotes a clear separation of concerns, with modules that encapsulate domain-specific logic and services. This makes the codebase much easier to maintain, as developers can focus on individual modules without worrying about unintended side effects in other parts of the application.

  3. Scalability and Evolution: With the modular approach, specific modules can be refactored or even extracted into microservices if scaling demands change over time. The system's modularity ensures that scaling can be focused on the parts of the application that need it, reducing the overhead of scaling the entire system unnecessarily.

  4. Team Collaboration: In a modular monolithic architecture, teams can work on different modules concurrently with minimal interference. Each module can have its own lifecycle, reducing conflicts and making it easier for large teams to collaborate on the same codebase.

Features of the Bonyan Library

  • Module Abstraction: Provides abstract base classes for defining and managing modules. Modules can depend on each other, forming a cohesive yet loosely coupled system.
  • Service Registration: Integrates smoothly with .NET Core's Dependency Injection (DI) framework, ensuring that modules can declare and use services independently.
  • Lifecycle Management: The library provides lifecycle hooks (OnPreConfigure, OnConfigure, OnPostConfigure, etc.) that allow each module to participate in the application's startup and configuration phases.
  • Modular Boundaries: Clear separation of domains through well-defined Bounded Contexts, making sure that each module focuses on a specific part of the business logic, minimizing cross-cutting concerns.

Example Use Case

Imagine an e-commerce platform developed using the Bonyan Library. Instead of having all functionalities (user management, product catalog, order processing, payments) as part of a single codebase, Bonyan allows each functionality to be encapsulated into its own module:

  • UserManagementModule: Handles all user-related operations, authentication, and profile management.
  • ProductCatalogModule: Manages product listings, categories, and inventory.
  • OrderProcessingModule: Handles orders, checkout processes, and related business logic.
  • PaymentModule: Deals with payment gateways, transaction processing, and payment records.

With each of these modules being independent, the system becomes easier to develop, test, and maintain. Changes in the payment logic, for example, will not affect user management, as the modules are designed to be decoupled and only communicate through clearly defined interfaces.

Summary

The Bonyan Library is designed to help developers leverage the benefits of modular monolithic architecture. By providing a robust framework for managing modules within a monolith, it makes the application easier to maintain, more scalable, and adaptable to changing business requirements.

Whether you are building a new monolithic application or refactoring an existing one, the Bonyan Library provides the tools needed to keep the codebase clean, modular, and ready to grow without the common pitfalls of traditional monolithic architectures.

Product Compatible and additional computed target framework versions.
.NET net8.0 is compatible.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages (4)

Showing the top 4 NuGet packages that depend on Bonyan.Layer.Domain:

Package Downloads
Bonyan.Layer.Application

Package Description

Bonyan.UserManagement.Domain

Package Description

Bonyan.TenantManagement.Domain

Package Description

Bonyan.UserManagement.Domain.Abstractions

Package Description

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
1.2.1 99 11/19/2024
1.2.0 190 11/17/2024
1.2.0-pre3 178 11/16/2024
1.2.0-pre2 108 11/16/2024
1.2.0-pre1 221 11/16/2024
1.1.9 245 11/14/2024
1.1.8 224 11/14/2024
1.1.7 220 11/14/2024
1.1.6 222 11/14/2024
1.1.6-pre3 228 11/9/2024
1.1.6-pre2 180 11/7/2024
1.1.6-pre1 185 11/7/2024
1.1.5 187 11/6/2024
1.1.4 200 11/6/2024
1.1.3 195 11/5/2024
1.1.2-pre7 188 11/2/2024
1.1.2-pre6 180 11/2/2024
1.1.2-pre5 176 11/2/2024
1.1.2-pre4 175 11/2/2024
1.1.2-pre3 190 11/2/2024
1.1.2-pre2 192 11/2/2024
1.1.2-pre1 183 11/1/2024
1.1.1 216 10/30/2024
1.1.0 158 10/28/2024
1.0.9 100 10/28/2024