In this somewhat of a long post, I will go over some of the lessons I and my team learned while building an event driven architecture at work, why did we build it, recommendations and watch-outs for anyone else thinking of doing the same. This is more of a field report from a real life environment so there is a generous helping of pragmatism around architecture and careful and deliberate avoidance of dogma and purism.

Many articles talk about the what of this style but in my view, not enough talk about the how. In this post, I am going to try and show one way to actually structure the solution to be more in line with the hexagonal ports and adapters style.

In part 2, I talked about my domain modeling thought process so this post is about trying to persist those objects for long term storage. Although the avenue for different data storage provider is always open with the kind of design I will talk about here, my default data store tends to be SQL Server […]

In part 4, I detailed the way I went about creating application services for my expense tracking application. In this final post, I will talk about the ASP.NET Core MVC application that I built with HTML5/Razor front end views on top of the application services. Remember the application services consumption model sketch from the last […]

Application services can be loosely compared with the business logic layer of the yesteryear with one key difference, application services don’t actually contain any business logic neither they enforce any business logic.

In this post, I will be going over the domain modeling in a bit more detail in terms of its design and show my thought process and the decisions I made and why I made them.

Having read Vaugh Vernon’s book on DDD implementation, I decided to portgrade (port+upgrade) my old clunky Windows based N-tier desktop expense tracking application to ASP.NET Core MVC application using some of the Domain Driven Design concepts I studied in the book.