In a couple of previous posts I had talked about anemic domain model that were caused by reverse engineering hibernate entities.
The powers that be, took a good interest in all of this and I was able to wrangle this into our schedule. My mandate was simple enough - find a better way to design.
I did a quick round of the top OO guidelines,
Of the three alternatives, Streamlined Object Modelling focussed on trying to reduce the design as applying a set of predefined patterns and templates. I felt there was nothing really new and revolutionary in Responsibility driven design. I liked Domain Driven Design since it focussed the whole design process around the domain, something which made a lot of sense.
In the book Domain Driven Design, Eric Evans introduces the basic concepts and moves on to explain the various building blocks and the refactorings that have to be undertaken.
In short term it's easier to stick to a very restrictive set of rules but as the pressure start mounting and you have team churn, people tend to relax their interpretation of the guidelines. So based on my experiences working on multi year projects, I have my own take on what works/not in long term. So I built on top of Eric's guidelines to create my own flavour/take on applying DDD in a contemporary project.
I'd be writing a series of posts on how to apply DDD with detailed instructions for each individual building block. I'll also add my experiences on what worked and what did'nt and some best practices that I came across. The building blocks, I intend to cover would be
- Why DDD / Ubiquitous Language
- Layers in DDD
- Entities
- Value Objects Part-1, Part-2
- Domain Services
- Aggregates
- Associations
- Repositories
- Policies and Specifications
- Modules
- Final Analysis and Conclusion
Technorati Tags: DDD, Domain Driven Design
1 comment:
Interesting to know.
Post a Comment