blatherings on software…
I wanted to reflect on and share my experience and learnings from big picture event storming sessions. Hopefully it will be helpful for others as well, but if there are tips and tricks I am missing please feel free to leave a comment or two
In this post, I will share my experiences leveraging Domain Driven Design strategies and Team Topologies to reorganise two product engineering teams in the Purchasing domain at Coolblue (one of the largest e-commerce companies in the Netherlands).
In this final part, I will review the current domain model, explore alternatives and make some model improvements keeping in mind the outcome of the design level event storm. Finally I will end with some DDD takeaways that should be applicable generally
A practice in domain (re)modeling using my pet project, guided by strategic and tactical DDD patterns.
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 … Continue reading Building Domain Driven Architecture in .NET – Part 3 (Repository Design)
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.
Artineering 