Over the last few years, we’ve run into scenarios that have led us down into a deep exploration phase on some of the “so-called” best practices in building quality software.
We have diligently followed the best practices as recommended by Microsoft and other giants only to find serious shortcomings when applications get massive.
As we started going down the rabbit hole, we discovered flaws in our approach, iterated to better approaches and eventually found a happy medium.
This is not a single post, it will be an exploration into different theories and will identify real issues solved from projects we have undertaken.
It is amazing how so many tutorials, code samples still indoctrinate the n-tier approach to application Development. If you are using this approach to development, I highly recommend you immediately stop and review the following Pluralsight courses immediately:
Approach 1 – Anemic Models
We took pride in building amazing Data Models, in fact we always started building applications from the Database Layer and delivered some amazing experiences to our customers.
The problem was that we were building all these “Anemic” data models that had no behavior associated with it. We had tons of POCO classes that more or less mirrored the persistence layer (aka the SQL Tables).
Most of our logic was written in the “Service Layer” that took care of getting these objects from the persistence medium and performed operations on it.
Approach 2- Anemic Models w/ Helper Classes and Extension Methods
As we started finding out that we were replicating a LOT of logic in the services, we started writing helpers. Helpers could be invoked on any object and it would open up a myriad of sub-helpers to accomplish the behaviors associated.
This approach works very well, mind you, it works so well that we almost started relying on these helpers for everything.
THE PROBLEM? Well, it still didn’t feel normal when coding. Dependencies between related entities started intermingling and it was nearly impossible to avoid circular dependencies as the business logic got more and more complex. More about this in future posts.
Approach 3 – DDD – Our Current Approach – Seems to be working fine as of this moment
After a lot of fighting with traditional, *recommended* approaches, we decided to give DDD a try.
We started with the concept of BOUNDED CONTEXTS and Aggregate Roots for a small sub-domain with the application to see if we could see benefits. We focused on building the Domain Model first. We really didn’t worry too much about persistence and focused on the various behaviors of the domain opposed to the persistence details. Persistence was only introduced towards the latter phases of the project when we were fairly confident that we got the basics right.
Approach 4 – In R&D – CQRS and Event Sourcing
We are currently evaluating CQRS and Event Sourcing, a natural progression of DDD to ensure that we benefit from the best of DDD and leverage some of the core tents of Command/Query segregation.
In Closing
As we mentioned earlier, this series is aimed at really digging down deep into the core of the Software Development and how procedural code evolves into Object Oriented code driven by Domain Driven Design. Stay tuned for future posts….
