Class Architecture And General Grouping of Features

Object names and namespaces are just the beginning of creating a class architecture.  We need to consider globally available values, data hiding, abstraction, and how to group features.  The old "is-a" and "has-a" questions are essential cogs in building out this piece.  You will be looking for common pieces of data, methods, and how they should relate.

It is incredibly easy to make your architecture too complex.  There is a broad range of "best practices" that try to provide the best general solution.  However, you are architecting a specific solution.  Thus, keep that in mind as you create the object architecture.  You should make every decision with supporting reasons for the related decisions.  The last thing you want to do is be asked why you made a specific decision, and your answer is "because that is a best practice."  You are not implementing a template; you are creating a solution, so do not be afraid to make it unique.

One of the complaints about coding tools is the extra stuff they include with a solution.  While the tools can speed development and design, they also tend to need some supervision.  Do not blindly trust these tools.  There may be some real valuable functionality that they provide.  Nevertheless, those results are useless when you do not understand what was done.  An architect will need to share not only the end-result but also an explanation of why the decisions were made.  This will be needed for implementation and future maintenance as well.

Let's step back a step and look for where to start building out your classes.  While the quick answer is always going to be in the requirements, there are better starting points.  The user stories not only give us requirements, but they also give us context and a better view of the overall application.  This higher-level view is needed for us to properly see how the pieces of the solution should work together.