Tip ExpenseTracker Backend | .NET Core • Clean Architecture • DDD • CQRS • Event Sourcing

[aekoky]

Sharing my backend solution for personal finance management, built with a microservices architecture for audit and expense tracking.
Designed for scalability, maintainability, and robust event-driven workflows.

𝗕𝗮𝗰𝗸𝗲𝗻𝗱 𝗧𝗲𝗰𝗵 𝗛𝗶𝗴𝗵𝗹𝗶𝗴𝗵𝘁𝘀:
• .𝗡𝗘𝗧 𝗖𝗼𝗿𝗲 — High-performance, cross-platform framework
• 𝗖𝗹𝗲𝗮𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 & 𝗗𝗼𝗺𝗮𝗶𝗻-𝗗𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝘀𝗶𝗴𝗻 (𝗗𝗗𝗗) — Separation of concerns & business logic encapsulation
• 𝗖𝗤𝗥𝗦 (𝗖𝗼𝗺𝗺𝗮𝗻𝗱 𝗤𝘂𝗲𝗿𝘆 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗦𝗲𝗴𝗿𝗲𝗴𝗮𝘁𝗶𝗼𝗻) — Distinct read/write models for optimized data operations
• 𝗘𝘃𝗲𝗻𝘁 𝗦𝗼𝘂𝗿𝗰𝗶𝗻𝗴 — Capturing state changes as event streams for auditability
• 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 — Separate Audit and Expense services for modularity and scalability
• 𝗣𝗼𝘀𝘁𝗴𝗿𝗲𝗦𝗤𝗟 — Reliable relational database
• 𝗥𝗲𝗱𝗶𝘀 — Fast caching layer
• 𝗞𝗼𝗻𝗴 𝗔𝗣𝗜 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 — Managing API traffic and security
• 𝗗𝗼𝗰𝗸𝗲𝗿 — Containerized deployment for consistent environments

Explore the full architecture and code here GitHub - aekoky/ExpenseTracker: ExpenseTracker is a modular, event-sourced .NET Core application designed to manage personal finances. It uses Clean Architecture, Domain-Driven Design (DDD), and Event Sourcing to deliver a scalable and maintainable system.

 

[Skydiver]

Perhaps I'm missing how your Audit and Expense services are Microservices. The point of a microservice is that everything with it is self-contained and it can be modified and updated independently of other code that is part of the application. But it looks like both of your microservices share common code between the two of them in the form of the various types in ExpenseTracker.Application.Common and ExpenseTracker.Domain.Account. So if you modify anything in that common code to try to do some kind of product enhancement or bug fix for one or the other feature, you will now have to also update the other service.

Yes it may not be a single monolithic application where both services are within the same web service/web app, but you still effectively have monolithic application due to the tight coupling between your services.

Anecdote: A team told us that they wanted to deploy their application into our IIS farm and the had 20 microservices. We told them, sure no problem. We noticed that whenever they deployed in the QA environment, they were often doing 15-20 webservice deployments for revision they had. Later when they moved to production, their sprint end deployment would touch all 20. Even their emergency changes for single bug hotfixes would touch all 20. I've got a feeling that they bought into the "microservices" buzzword without really understanding the intent of the design pattern.

 

[aekoky]

Perhaps I'm missing how your Audit and Expense services are Microservices. The point of a microservice is that everything with it is self-contained and it can be modified and updated independently of other code that is part of the application. But it looks like both of your microservices share common code between the two of them in the form of the various types in ExpenseTracker.Application.Common and ExpenseTracker.Domain.Account. So if you modify anything in that common code to try to do some kind of product enhancement or bug fix for one or the other feature, you will now have to also update the other service.

Yes it may not be a single monolithic application where both services are within the same web service/web app, but you still effectively have monolithic application due to the tight coupling between your services.

Anecdote: A team told us that they wanted to deploy their application into our IIS farm and the had 20 microservices. We told them, sure no problem. We noticed that whenever they deployed in the QA environment, they were often doing 15-20 webservice deployments for revision they had. Later when they moved to production, their sprint end deployment would touch all 20. Even their emergency changes for single bug hotfixes would touch all 20. I've got a feeling that they bought into the "microservices" buzzword without really understanding the intent of the design pattern.

You're absolutely right — this isn't true microservices architecture. Sharing code between services, like having a common ExpenseTracker.Domain project, goes against the core principles of microservices. It's a clear microservices smell that leads to tight coupling and defeats service autonomy.

That said, to clarify my vision: I'm implementing microservices using the CQRS pattern, where each responsibility is isolated. I have one service dedicated to the write side — responsible for saving events and modifying state — and a separate service for the read side, focused on querying data. This separation allows both services to grow, scale, and evolve independently.

Thanks to your feedback, I now realize the mistake of sharing domain logic across services. The correct approach is to have a shared contracts library containing only integration event DTOs. This allows services to communicate effectively without violating boundaries — preserving autonomy and maintaining a clean architecture.