3 Common Software Design Approaches
How do you design software? Are you a “cowboy coder” who starts coding immediately to get it done, quick designer who sketches out a quick design before starting, or acomplete architect who tries to hammer out all details before even writing the first line of code? As most people would say, it really depends on what is being done and the scale and size of the project. I very rarely do no design, unless it’s for a quick throw away utility.
For any piece of software that is going to be maintainable and testable, you really have to have a good thorough design. This does not mean you have to work out every detail before you start, but you at least need to have an approach to your design that allows you to easily makes changes without easily breaking the application. With this in mind, I am going to go over a few common approaches to developing software:
Data Driven
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.
This has been far from a complete explanation of all the possible approaches, and really does not do any of the approaches mentioned justice in fully explaining them. The goal here was to give a quick overview of a few common approaches, with the hopes that you will or are using one of these. If you are unfamiliar with any of these approaches, I hope you search for more details, as they provide really good patterns to follow when coding.
Comments
About Author
trent January 26th
I often find myself learning the ins and outs of a project by it’s data model. Especially if the project is to re-work an existing application. On new projects I like to lay out the ground work before doing much coding, create my models, at that point I would be at the same position as reworking an existing app.
Bryan January 26th
I will agree. More times than not, the database is all you have to go by with a previous application. I have been doing a lot of new applications lately, so I am trying different approaches from the beginning to see how I like each one.
Ryan S January 30th
+1 for TDD for me, though I’ve not yet been in a situation where I could really take advantage of it… Small to midsize projects especially tend to be data driven (which is where my experience has been so far), but often this means that the project cant handle changes or exceptions to the data model down the road. I like the idea of going a step farther with TDD and using pre-written tests as the design documentation itself, so that even a total refactoring of the project has a trail blazed for it already.
Add Yours
YOU