As I look back over an aggressive software development career now spanning back into the late nineties I stand at what I consider to be a very fortunate point. I have deep experience with C++, C# (all of .NET), a plethora of distributed systems environments and tools, and more XML, messaging and database knowledge than is probably healthy for a developer. I have enough experience to know when and why to follow certain patterns when developing systems and what to avoid (largely through trial and error – emphasis in the error part). I also have an amazing job with a fantastic company in which I get to help budding developers and architects grow their careers. This is the best part of my job. These people push me to be my best and rethink everything I know (or think I do) all the time. While doing so I was inspired to distill the essence of my software design approach into as few words as possible while still being entertaining (without the last part I was at 200 words).
As a note I’ve not included this introduction in the word count.
Start with use cases
Yea, maybe I’m dating myself here, but ultimately there is no real substitute for this. All software starts and ends with a user otherwise it wouldn’t exist. You can use stories if you like, but what you would start with in that case are notes about stories (from your conversations). Look at what you have; it could be something like (randomly grabbed these from an old project):
As a customer I would like to be able to view my account balance
As an AR clerk I need to be able to apply a credit to an account
Extract core entities and services
I like to print these out myself (or copy the cards), but if you’re working in a word processor that’s fine too. At this point Circle the nouns. These are your basic system entities. Now highlight the verbs; these are the services (whether they are web services or class methods, they are still services – go read Booch).
In our examples above we have the following results.
As a customer I would like to be able to view my account balance
As an AR clerk I need to be able to apply a credit to an account
I’ve purposely not circled balance because that’s really more of an attribute of an account. Already I can see a few things emerging. Clearly the account entity is important, it’s in both stories. Continue doing this until you whittle down the most recurring entities and the services that involve them. You’ll have a little decision making here as to what is really an entity and what is an attribute.
Return the focus to the user
Now zoom back out to the user level / UI. Validate that your assumptions are correct and gather the entity specific attributes from the user or UI (again if it doesn’t get seen, you can probably defer it for a little while longer). The focus on this user part is really to drive back to the service. Again I use that term service because this may be a single operation / method or it may be many that are related (a composite service). The only thing I can really say for sure is that it shouldn’t live in your entities. It mixes data and processing / functionality too much and introduces coupling. These are really the business services; we’ve left all the infrastructure out (like repositories). That’s much more aesthetic and won’t fit into 500 worlds, but now is when you want to do it.
Create storage
Notice this is my last step. There’s a reason for that. There was a time when data driven applications (or designs) were all the rage, but what everyone forgot was that the data still came from users. Coupling data too closely to the core design can be dangerous. Here you have to make many choices about how to store data. By leaving this last, behind repositories, you’re free to choose whatever implementation you like.
Conclusion – also not in world count
Our craft is really just that – a craft. There are a lot of grey areas and many tradeoffs to be assessed. Parts of it are as hard as science like memory management, which even in managed languages is still there, parallelization, and concurrency. But other parts are much more subjective and require come critical skills and even language skills (as seen above) that are also vitally important to success.
danrosanova 