Anyway, I started to create a repository class - see Eric Evans Domain Driven Design (DDD). This class would be responsible for handing me my SalesOrder aggregate root entity from some obscure infrastructure that my domain didn't need to know about. I found that I was struggling with what to name this class. I was torn between SalesOrder (which seemed more pure domain language-ish but could cause me later confusion between that and my SalesOrder entity, and SalesOrderRepository (which gave me the separation I craved but didn't seem to fit with Uncle Bob's clean code naming guidance, nor Evan's ubiquitous domain language!).
I Googled around a bit as is my wont, and found a really interesting webpage. Let me share with you what it advised:
Instead of calling my repository either SalesOrder or SalesOrderRepository, what if I called it AllSalesOrders. This is:
- Very domain languagey
- Forces me to remember at all times that I am operating on/with a list
- Gives me some really elegant looking client code like allSalesOrder.For(customer) and allSalesOrder.ForDeliveryOn(date)
- Makes it pretty darn easy for me to spot when I've broken the single responsibility pattern allSalesOrder.AddCustomer(customer)