Last time, we continued a discussion around how to organize classes inside your domain model. We defined important domain model elements: Entities, aka Reference Objects, and looked at their relationships. This month, we will review the options for loading Entities into memory.

Potluck Principle of Getting Objects You Want

The Potluck Principle states that if you need to obtain a reference to an Entity in your code, you have the following three options:

1. You may be able to create the Entity yourself
2. You may be able to ask another object to give the Entity to you
3. You may be able to reconstitute the Entity from a previously stored state

Choosing the right option

The option #1 is usually implemented via a constructor or a factory. It works well when you need to create a new entity object, not yet tracked by the application.

As we discussed last month, Entities span through long periods of time and run across multiple systems. Unless you are writing a data entry application, you are going to work with existing Entities a lot more often than with new ones. When you need to create an existing Entity, use the option #2 or the option #3.

Let us take a look at the last month's example: User logs in into the system to check the status of their loan applications. Assuming we have a Person loaded, how shall we obtain their Applications?

To enable the option #2, design the Person class with a method or property that returns the Person's Applications. I generally prefer to pass a qualifier, such as loan type or date, that would transform one-to-many relationship between Person and Application into one-to-one with a qualifier, but this is a topic for another conversation. For now, let us assume that the Person class defines the Applications property that returns a list of Applications. This requires you to either get the Applications when the Person object is loaded into memory or implement a lazy load mechanism to defer loading Applications until the Applications property is called.

To enable the option #3, design the ApplicationRepository class with a method that returns a list of Applications for a given Person: "IList FindByPerson(Person person)".

Domain Model Structure

My preference is to place repository interfaces in the model and move repository implementation into a separate Persistence library. Keeping repository interfaces in the model helps clients understand how entities are supposed to be loaded into memory. Having repository implementation separate from the model keeps the model free from infrastructural detail.

Happy coding! To be continued...

Starting January 2010, articles in our Architect column will be published once every two months. Happy coding!

Our monthly column have just celebrated its 2-year anniversary. Altogether, we reviewed 24 books in 2008 and 2009. They are all listed below. We will continue writing reviews in 2010, but we will do that at a less frequent schedule: one book every two months. Happy reading!

2009

1. Corey Ladas, Scrumban: Essays on Kanban Systems for Lean Software Development
2. Ingrid Bens, Facilitating with Ease! Core Skills for Facilitators, Team Leaders and Members, Managers, Consultants, and Trainers.
3. John Shook, Managing to Learn. Using the A3 management process to solve problems, gain agreement, mentor, and lead.
4. Jean Tabaka, Collaboration Explained. Facilitation Skills for Software Project Leaders.
5. Esther Derby, Diana Larsen, Agile Retrospectives. Making Good Teams Great.
6. Durward K. Sobek II and Art Smalley, Understanding A3 Thinking. A Critical Component of Toyota's PDCA Management Process.
7. Patrick Lencioni, The Five Dysfunctions of a Team.
8. Martin Fowler, Patterns of Enterprise Application Architecture.
9. Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience
10. Steve Resnick, Richard Crane, Chris Bowen, Essential Windows Communication Foundation. For .NET Framework 3.5.
11. Mike Rother, John Shook, Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA.
12. Neil Davidson, Don't Just Roll the Dice: A usefully short guide to software pricing.

2008

1. Tom DeMarco, Tim Lister, Waltzing with Bears: Managing Risk on Software Projects.
2. Eric Evans, Domain Driven Design.
3. Robert C. Martin and Micah Martin, Agile Principles, Patterns, and Practices in C#.
4. Norman L. Kerth, Project Retrospectives. A handbook for team reviews.
5. Michael N. Kennedy, Product Development for the Lean Enterprise: Why Toyota's system is four times more productive and how you can implement it.
6. Gerald M. Weinberg, The Secrets of Consulting: A guide to giving and getting advice successfully.
7. Mike Cohn, Agile Estimating and Planning.
8. Jeffrey Liker, David Meier, Toyota Talent: Developing Your People The Toyota Way.
9. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software.
10. Michael Kennedy, Kent Harmon, Ed Minnock, Ready, Set, Dominate: Implement Toyota's set-based learning for developing products and nobody can catch you.
11. Cliff Atkinson, Beyond Bullet Points: Using Microsoft® Office PowerPoint® 2007 to Create Presentations That Inform, Motivate, and Inspire.
12. Eliyahu M. Goldratt, The Goal: A Process of Ongoing Improvement.