StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POWhat is a practical way to model lookup tables in Domain Driven Design (DDD)?
text
Body
copied!<p>I'm just learning DDD (Eric Evans book is open in front of me) and I've come across a problem that I can't find an answer for. What do you do in DDD when you're just trying to get a simple list of lookup records?</p> <p>Ex.</p> <p>EmployeeID: 123<br /> EmployeeName: John Doe<br /> State: Alaska (drop-down)<br /> County: Wasilla (drop-down -- will be filtered based on state).</p> <p>For example, let's say that you have an Employee domain object, an IEmployeeRepository interface and an EmployeeRepository class. This will be used by a UI to show a list of employees and individual details. In the UI, you want to use a drop-down for the State and County where the employee lives. The Available counties will be filtered based on which state was chosen. </p> <p>Unfortunately, the database tables and the UI look very different. In tblEmployees, it contains State Code=AK and County Code=02130, not the State and County Names.</p> <p>The old way (before I began this DDD quest) would be pretty straightforward, just create 2 queries and use a DataReader to populate the drop-downs. Underneath the display in the drop-downs is the value, which gets automatically used in form posts.</p> <p>With DDD, though, I'm not sure how you're supposed to do this. I first started by creating State and County objects as well repositories and interfaces for the repositories. However, writing 4 classes + 2 interfaces and the plumbing in the hbm.xml files + Employee Business objects seems like overkill for just 2 queries for 2 drop-downs. There has to be a better way, doesn't there? I'm not changing the records in the State or County tables any time soon and even if I did, it wouldn't be through this application. So I don't really want to create business objects for State and County if I don't have to.</p> <p>The simplest solution that I see is to just create a helper class with methods that return dictionaries, such as GetStatesAll(), GetState() and GetCounties() and GetCounty(), but that just feels wrong from a DDD perspective. </p> <p>Please help. How can I use DDD without overengineering just a couple of simple lookups?</p> <p><b>Final Solution</b> I think that I finally found my answer through experience, which was to put the GetStates() method into its own Data Access class, though not a repository class. Since I was only doing read-only access, I threw it into a struct DTO. Since the database was small, I threw them altogether into a single class, like Todd below described. </p> <p>My conclusions:</p> <ol> <li> Lookup tables are NEVER value objects, because lookup tables ALWAYS have an identity. If they didn't have an identity, you'd have duplicates, which wouldn't make much sense. <li> Read-only lookup table can have a repository, but probably don't need one. The goal of a repository is to reduce complexity by forcing access only through the aggregate. Going through the aggregate provides you with a way to ensure that business rules can be enforced, such as not adding tires if you don't have a car. <li> If you allow CRUD maintenance on the lookup table, then it makes sense for the lookup table to have its own repository. <li> The fact that I ended up storing the codes as structs doesn't make them "value types". Fowler says in POEAA that a struct is a value type. That's true, structs are immutable, which is why Fowler says that they are "value types", however I was using them differently. I was using structs as a lightweight way to pass around DTOs that I didn't ever plan on changing after their initial creation. In truth, the structs that I used did, indeed, have identities, but since they were read-only they worked as structs. <li>One pattern that I've been using that I don't see much elsewhere is to make primary key fields be immutable. They're set by the constructor, but they're read-only (not private accessors) and cannot be changed once the object is created. </ol>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload