Skip to content

Commit d3d67e5

Browse files
committed
- Add Refactoring
1 parent b5a671a commit d3d67e5

File tree

57 files changed

+1176
-181
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

57 files changed

+1176
-181
lines changed

CHANGELOG.md

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
# Changelog
2+
3+
All notable changes to SourceFlow.Net will be documented in this file.
4+
5+
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
6+
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
7+
8+
## [1.0.0] - 2025-01-28
9+
10+
### Added
11+
12+
#### Core Framework (SourceFlow.Net)
13+
- Complete event sourcing implementation with Domain-Driven Design (DDD) principles
14+
- CQRS pattern implementation with command/query segregation
15+
- Aggregate pattern for managing root entities within bounded contexts
16+
- Saga orchestration for long-running transactions and workflow management
17+
- Event-first design with comprehensive event sourcing foundation
18+
- Command and event publishing/subscription infrastructure
19+
- View model projection system for read-optimized data models
20+
- Support for multiple .NET frameworks:
21+
- .NET 10.0
22+
- .NET 9.0
23+
- .NET Standard 2.1
24+
- .NET Standard 2.0
25+
- .NET Framework 4.6.2
26+
- OpenTelemetry integration for observability and tracing
27+
- Dependency injection support via Microsoft.Extensions.DependencyInjection
28+
- Structured logging support via Microsoft.Extensions.Logging
29+
30+
#### Entity Framework Store Provider (SourceFlow.Stores.EntityFramework)
31+
- `ICommandStore` implementation using Entity Framework Core
32+
- `IEntityStore` implementation using Entity Framework Core
33+
- `IViewModelStore` implementation using Entity Framework Core
34+
- Configurable connection strings per store type (separate or shared databases)
35+
- Support for .NET 10.0, .NET 9.0, and .NET 8.0
36+
- SQL Server database provider support
37+
- Polly-based resilience and retry policies
38+
- OpenTelemetry instrumentation for Entity Framework Core operations
39+
40+
#### Architecture & Patterns
41+
- Clean architecture principles
42+
- Separation of concerns between read and write models
43+
- Event-driven communication between aggregates
44+
- State preservation and consistency guarantees
45+
- Extensible framework design for custom implementations
46+
47+
### Documentation
48+
- Comprehensive README with architecture diagrams
49+
- Developer guide available on GitHub Wiki
50+
- Package documentation and XML comments
51+
- Architecture diagram showing complete system design
52+
- Roadmap for future cloud provider support (v2.0.0)
53+
54+
### Infrastructure
55+
- NuGet package generation on build
56+
- GitHub Actions CI/CD pipeline integration
57+
- CodeQL security analysis
58+
- Symbol packages for debugging support
59+
- MIT License
60+
61+
[1.0.0]: https://github.com/CodeShayk/SourceFlow.Net/releases/tag/v1.0.0

README.md

Lines changed: 46 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -19,22 +19,54 @@ SourceFlow.Net empowers developers to build scalable, maintainable applications
1919
* 📊 Event-First Design with Event Sourcing Foundation
2020
* 🧱 Clean Architecture
2121

22-
### Concept
23-
**v1.0.0**
24-
- `Aggregate` wraps the `root aggregate` entity that you wish to manage within a domain bounded context (microservice). Changes are applied to aggregate entity by publishing commands.
25-
- `Saga` is a long running transaction that subscribes to `commands` to apply actual updates to aggregate entity. Saga basically `orchestrates` the success and failure flows to `preserve` the `state` of `root aggregate` accordingly. Saga can also publish `commands` to `itself` or `other` saga's. Saga can be defined to raise `events` when handling commands.
26-
- `Events` are published to `subscribers`. There are two subscribers to event - ie. i. `Aggregates` ii. `Views`
27-
- `Aggregate` subscribes to `events` to publish `changes` to root aggregate based upon `external` stimulus. ie. potential changes from any other saga workflow that could affect the state of Aggregate in context.
28-
- `View` subscribes to `events` to `write` data to `view model`, view sources `transformed` data for interested viewers. ie. `UI` (viewer) could read data from view model (with eventual consistency).
29-
30-
**v2.0.0**
31-
- `Command Dispatcher` will dispatch `commands` to `Cloud`. It basically targets a specific command `queue`.
32-
- `Command Queue` is the queue designated for the `bounded context` (microservice). When command is sent to this queue it gets dispatched to subscribing `Saga's` in the domain context.
33-
- `Event Disptacher` will dispatch `events` to the `Cloud`. It basically publishes to certain `Topic`.
34-
- `Event Listeners` is a bootstrap component `listening` to subscribed `topics`. When it receives the `event` for the topic then it dispatches to subscribing `Aggregates` and `Views` within the domain context.
22+
### Core Concepts
23+
24+
#### v1.0.0 Architecture
25+
26+
**Aggregates**
27+
- An `Aggregate` encapsulates a root domain entity within a bounded context (microservice)
28+
- Changes to aggregates are initiated by publishing commands
29+
- Aggregates subscribe to events to react to external changes from other sagas or workflows that may affect their state
30+
31+
**Sagas**
32+
- A `Saga` represents a long-running transaction that orchestrates complex business processes
33+
- Sagas subscribe to commands and execute the actual updates to aggregate entities
34+
- They manage both success and failure flows to ensure data consistency and preserve aggregate state
35+
- Sagas can publish commands to themselves or other sagas to coordinate multi-step workflows
36+
- Events can be raised by sagas during command handling to notify other components of state changes
37+
38+
**Events**
39+
- Events are published to interested subscribers when state changes occur
40+
- Two primary event subscribers exist in the framework:
41+
- **Aggregates**: React to events from external workflows that impact their domain state
42+
- **Views**: Project event data into optimized read models for query operations
43+
44+
**Views**
45+
- Views subscribe to events and transform domain data into denormalized view models
46+
- View models provide optimized read access for consumers such as UIs or reporting systems
47+
- Data in view models follows eventual consistency patterns
48+
49+
#### v2.0.0 Roadmap (Cloud Integration)
50+
51+
**Command Dispatcher**
52+
- Dispatches commands to cloud-based message queues for distributed processing
53+
- Targets specific command queues based on bounded context routing
54+
55+
**Command Queue**
56+
- A dedicated queue for each bounded context (microservice)
57+
- Routes incoming commands to the appropriate subscribing sagas within the domain
58+
59+
**Event Dispatcher**
60+
- Publishes domain events to cloud-based topics for cross-service communication
61+
- Enables event-driven architecture across distributed systems
62+
63+
**Event Listeners**
64+
- Bootstrap components that listen to subscribed event topics
65+
- Dispatch received events to the appropriate aggregates and views within each domain context
66+
- Enable seamless integration across bounded contexts
3567

3668
#### Architecture
37-
<img src="https://github.com/CodeShayk/SourceFlow.Net/blob/v1.0.0/Images/Architecture-Complete.png" alt="arcitecture" style="width:1200px; hieght:700px"/>
69+
<img src="https://github.com/CodeShayk/SourceFlow.Net/blob/master/Images/Architecture-Complete.png" alt="architecture" style="width:1200px; hieght:700px"/>
3870

3971
### RoadMap
4072

0 commit comments

Comments
 (0)