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)
Just out of curiosity, how does SalesOrderRepository violate the CleanCoders naming guidelines in you opinion? I must admit it's been some weeks now since we watched that, but you hadn't named it SalesOrderDatabase for example.
ReplyDeleteIs there an argument for keeping your repository class still so you now have two classes with two separate jobs? One to handle aggregate operations on your business entity, and the repository class to handle the persistence of your business entities?
Hi Russ, you are correct that SalesOrderRepository doesn't really break naming conventions AFA CleanCoders goes, but I maintain that it does break the DDD concept of a ubiquitous domain language. A colleague commented via twitter that OrderBook might be a better name since if it were a paper-based system, that is where we'd store the orders.
ReplyDeleteI think that there is perhaps a case for two objects (a strategy pattern for example) to delegate persistence to in this case. When considering OrderBook as the name, I thought that I might easily add behaviour or structure onto a class of that name that wasn't a repository responsibility. That's why I prefer allSalesOrders - the client code you're inclined to write seems to lend itself to keeping you on the straight and narrow!
You can now recover knowledge from pen drive simply. Pen drive brings us unpredictable risk along with nice convenience. the location is always accustomed to avoid wasting our handy files in a pen drive rather than in an exceedingly laptop.
ReplyDeletewindows 7 boot disc
Thanks guys, for sharing such informative data.
ReplyDeletec2logix.com/
Great webpage brother I am gona inform this to all my friends and contacts.
ReplyDeletepay per head service
Congratulations c_phillips! Thank you so much for taking the time to share this exciting information. Click Here
ReplyDelete