Here as an interesting question that popped up at my user group meeting last night, when you are starting a new program (green field development), where do you get started? I find these questions interesting because there really is no correct answer, but a persons answer will tell you something about how they problem solve.
Depending on who you ask you will likely get one of two answers. If you are talking with a data guy, he will say to start with the database. If you are dealing with a visual guy, he will say to start with the UI. Historically, I did a conglomeration of those two ideas, creating both the UI and the database at the same time, letting the two drive each other. But I’m weird, I’m a visual/data guy.
Lately though, I’ve started to thing about a third approach. Starting in the middle. No UI, no database, just the data classes. This approach has been spurred on buy a couple of things. Namely, test driven development (TDD), design patterns, and domain driven design.
TDD really is the glue that allows all of this to happen. I can start in the middle because I can run the code in the middle any time I want. I just have to write a test. No having to wade through multiple layers of UI to test out some small chunk ok UI is a great productivity gain for me.
Next is design patterns. This is what gives you a reference for how to approach your code. That said, this isn’t about making everything absolutely perfect from the get go, but it is nice to know where you are going to made your comprises early on.
But all of that does not explain where I begin. That is where Domain Driven Design (DDD) kicks in. For those not familiar with the concept, you can read up on wikipedia, buy The Book, or buy one of the various other references. One of the concepts in DDD (I’m still reading the book) is setting up something called a ubiquitous language.
The ubiquitous language is actually trying to solve a problem that I have seen happen on many projects I’ve been apart of (but not always my fault). At some point there is a linguistic difference between the nouns that the customer uses and the nouns that the programmers use. By focusing on the language first, you are attempting to head that off at the pass.
These nouns consist of your domain classes and your tables and columns, they move everywhere…but not always consistently. Consistency does matter. Inconsistency is what leads to rather confusing conversations with people and everyone scratching their heads about “what just happened”. So, this is the middle that I start with.
But before you start…
One of the other guys in the group was an actual data guy. The systems he has written worked with more data than yours does. Trust me on that. Historically, his biggest consideration was data input speed. I don’t think I would start in the middle if that was my biggest concern. In that case you do start with the database, you tune for speed. You also don’t use as many domain classes, and you tend to throw away your ORM solution and just hit the database layer directly via Ado.Net.
But lets face it, that doesn’t happen very often. Most business applications aren’t going to touch what the architecture can take. It is amazing how many horribly written applications with very inefficient code run just fine. Most of my speed issues could be solved by indexing tables and changing generic lists to generic dictionaries (more on that later). Architect your applications for how they are going to be used. Most of my web applications have a max usage of 100 simultaneous users. If the data access is slightly slower I’ll take that hit for programmer efficiency. If you are designing Amazon.com, you code for through-put.
OK, someone is going to disagree with this…I can already feel it. Please take a moment to register your displeasure in the comments. I would love to hear it.
I work for a consulting company which produces custom software.
Most often we start by designing/creating the database, then doing the “administration” side which is basically CRUD for that schema. Once done, we move on to the front end, or the “interesting part”.
I have become frustrated with this monolithic approach. The admin portion resembles how *we*, the developers, think about the data, not how the client does.
It also ensures that the client hates the admin portion unless they don’t know any better.
The entire enterprise comes down to a single question: are you making this problem easier on yourself, the developer, or on the user? Any UI based on direct CRUD operations is definitely the former.
When you start “in the middle”, i.e. a domain sans UI or storage, you get a “pure” view of the problem: no contorting it to meet the needs of a particular application layer.
This allows you to project your domain to UI or storage as needed. It also allows you to define your nouns and verbs without regard for their connotations in a particular layer.
Point being, when you start with the UI, you code your problem for the UI; when you start with the DB, your code your problem for the DB; when you start with the domain, you code your problem for the solution.
OK, I will disagree. Sort of.
I fervently agree that starting with the data tier is flat wrong. I recently told a tem at work that if they bring an ERD to a sprint review I will take in into the parking lot and burn it. As an example 🙂
On the other side, I find trememdous value in building mockups (not working code at all, just some pictures) of the User’s Experience in an application and a domain vocabulary at the same time.
I would propose that this makes more sense than starting with a middle tier, becuase your customer rarely thinks in those terms. If I am designing a system for end users, the UI is their world. Let them live in it and let them force the build of the common vocabulary in that paradigm.
Typical users (and this may not mean client) do not know about the middle tier. This means that we need to be aware of our biz layer as we work though that UI with the client. When they come up with a potential screen that you can see conflicting in that biz layer, work it out with them before you get to code.
So, in a nutshell, mockups and vocabulary first. Iterate on the mockups and vocabulary with the client before you write a line of code.
Then thin slice the application as you build it out a feature and a screen at a time, including the domain. Evolve the domain as the features actually come online.
@David: You bring the ERD diagram, I’ll bring the hot dogs and beer.
I am also finding more value in mocking up the UI, just pictures, no code, before hand. It gives the customer some degree of assurance. Which promptly get trashed when the real world UI constraints get thrown in.
But after that, you have a bunch of pretty pictures and no code, no tables. Do you start creating the UI, just attached to nothing?
I still think it makes sense to start with the domain at that point. You need to have your naming scheme down, and I use that to help drive the UI. But in case you missed that last part…I’m only creating the parts of the domain that I need right then…for the UI that I’m going to be working on. Agile development is still the name of the game.
@Chris
I start the UI doscussions on a whiteboard and only move them into code after the vocabulary is understood. It sounds like we work similarly, actually.
Too bad. Agreement is not typically as fun as arguing 🙂
I’d agree with the domain model being the right place to start these days. ORM will basically build your database from that, and the performance-critical pieces can then be tweaked. With more enterprise software being integrated, the GUI has become just one endpoint the domain model feeds in addition to syndication feeds, web services, and other interfaces.