public class House
    {
        public int HouseID { get; set; }
        public Address HouseAddress { get; set; }

        private House() {}

        public static House GetHouseByID(int id)
        {
            //Get house by the ID
        }

        public static House GetHouseByOwner(int ownerID)
        {
            //Get house by the owner id
        }

Have you actually thought about trying to use a camera on a device like this? How would you hold it? Would you have to set it on a docking station, or are you going to hold in with your hands and give the person you are talking to the Blaire Witch Project I need to puke feeling? I am sure this will eventually be a feature of the device, but I don’t see how the experience could be good unless it is on a stationary dock. At this point, it is trying to be a laptop.

No Multitasking

I would love to hear you thoughts on your solution for this? It must intuitively manage the applications without letting all of them continue to run and kill the battery. It has to be simple enough that you don’t even feel like you have to worry about it. That is the experience that Apple is trying to create.

I would love to have the ability to listen to my Pandora radio while I am reading or working on a document. The issue I have with this is I don’t really know how this could be done without creating the management nightmare they were trying to avoid on the iPhone. I understand it is a limitation, but it is also nice to not to have to worry about:

• Do I need to quite this application, or close it? Because I don’t think I will need it for a while?
• I will just leave all my apps open, so they will load faster. What happened to my battery life, this device sucks.

Yes, these are very simple things, but they are things I honestly would like to not have to worry about.

I don’t want to make this post extremely long and cover every point because you probably get my drift. But my main point is this: many people are quick to complain that it does not have a specific feature. Before you do that, realize that this is a new device for a new market. It is not being made to give you everything that you need, because it then would lose everything that it is trying to be.

Data driven design starts with data. This means designing the database first, then developing the rest of the application around that. This approach is very common for business application. If you use .NET, many of its components were designed for this very approach.

I have used this approach many times. Once you have an understanding of the entities and their relationships, you have a pretty good understanding of how the application should function. With this, I have found that a lot of good questions come from designing the database, and a pretty good application design is a result of the answers to these questions.

Domain Driven

Domain driven design starts with the logical entities. This means designing the classes that will be used to hold the data. At this point, it sounds a lot like the data driven approach. But since the classes also hold methods, this approach goes further by also designing all the behaviors of the entities.

This is not to say that a data driven approach does not focus on behaviors at all, but domain driven uses objects that can actually perform the actions, so for me, it is a cleaner approach to holding a better design.

I like this method for the same reasons I liked the data driven, because they are both designing entities and their relationships, and that makes you ask a lot of important question. But I like this approach more due to more focus on the behaviors. This allow for even more questions, and a more complete design to start with.

Test Driven

Test driven development starts with the behaviors. Once a behavior has been defined, a test is written first for all possible outcomes of that behavior. Once the test is written, the case is verified as failed (red). This is to check the integrity of the test. The next goal is to implement the behavior and test until pass (green). This step could also be considered a prototyping phase with the goal only being to pass the test. With this, the next goal is to clean up the code and separate the logic into functions where needed, put simply: (refactor). These steps are easily described as “red/green/refactor”.

I have yet to attempt this approach on a project. However, I have a new project in the requirements gathering phases now, and I expect to use it then so I will report back.