https://i.stack.imgur.com/YZXZN.png (I’m currently not allowed to embed images)
I could really use some help with my class model above. I’m ashamed to say that I have been one of “those” developers that learned object orientation at university, wrote the exams, aced them but then never set about implementing the principles in my real world code. I never truly sat down and considered my application design before beginning the codification of it. Thus my design and coding skills have been slowly dying and stagnating under the weight of monolithic legacy banking application development and maintenance. After years of this I’ve decided that it’s definitely time for a change! I’ve been delving deep into the world of design patterns, DDD, NoSQL, DI, etc etc. The last 2 weeks have been a really intense experience for me, and at times I think I was nearly brought to tears at the sheer volume of best practices and tech that I had missed while working for large corporations and banks. I simply couldn’t believe how far removed I had been from cutting edge tech and good design approaches for so long, and the sudden swathe of everything threatened to send me into a state of coding paralysis! I simply could not start coding, as I felt my design needed more tweaking, or I needed more studying on a particular topic. Enough is enough though, and I need to crack on and at least make a first iteration on the project.
Anyway, enough of the drama, on to my issue:
I have begun work on the model creation for my golfing app. Wanting to adhere somewhat to DDD and also wanting to make use of NoSQL (RavenDB), I set about with the following requirements.
- My platform stack is Windows / IIS / MVC 3.0 / RavenDB
- I need to find my aggregate roots! I have set about defining them as the only elements in my system that are capable of persisting in their own right. Everything else I’ve simply deemed a “sub-component” of the aggregates. Note that no real behaviour has yet been defined.
- My aggregate roots will be the only classes to actually persist in my RavenDB doc store, and they will persist “as-is”. Having large tree-like class structures would appear to be a best case scenario for RavenDB in terms of performance benefits realised.
- I don’t feel the need for a repository layer (been following some of Ayende’s posts), as the RavenDB API feels fluent and quite lightweight. I’ll be simply opening and closing my sessions via Custom Action Attributes on my controllers where required. I’ve seen that without the repository layer testing might be tricky, but surely I should be able to simply mock some “in-memory” domain objects?
- Writes to the DB will happen in a separate service layer
- At one point I stopped and asked myself: “Where on earth am I going to put my domain behaviour!?”. The general consensus from searching the web would seem to indicate I should leave my domain (entities) void of any behaviour (business logic) and have it all handled in my service layer. But after reading some Eric Evans, I’m convinced that as much of my domain behaviour should exist right there… in the domain!
Questions
– As a bona fide noob in the area of DDD and architectural design, am I at least on the right track, or am I destined for destruction?
– Any thoughts, admonishments, constructive criticism and insights into the above would be greatly appreciated!
To counter being overly academic about it all and be stuck in analysis too long: First make it work. Then make it pretty.
Put behavior near data as much as possible. Use services where you can’t cleanly assign a responsibility to a class (e.g. should a ‘transfer money’ method be on an SavingsAccount class?). Services can be part of an aggregate.
Do use repositories (I don’t agree with Ayende). You mention using a separate service layer for DB writes. Repository is a perfect interface to put that layer behind. It’s also a perfect testing seam.
Didn’t look at your class diagram thoroughly, but you may be overusing inheritance here and there. Favor composition over inheritance. Inheritance can rear it’s ugly head quite quickly.
When choosing aggregate roots, an important criteria is life cycle. When the aggregate root dies, everything else in the aggregate dies also. The aggregate root is also in control, everything outside the aggregate passes through it. When in doubt just create a lot of them (single entity aggregate). With a document database you would typically store a document per aggregate, so that does matches somewhat with how you choose them. Store IDs of references to different aggregates.