The Domain Model

Domain Modeling

When I was initially planning what I was going to accomplish on my sabbatical, I had a strong desire to learn about domain modeling. Previously, I had come across Eric Evan's book on domain modeling, Domain-Driven Design: Tackling Complexity in the Heart of Software, and I knew it was a seminal work on the topic. Being a pretentious NOOB, I actually read at least some of the book before I even had a legit web job, and I was bound determined to come back to the book now that I was on my way to becoming a bona fide web developer. You could even here me asking questions about where the "domain model" was at my previous job. So, I vowed to spend time learning about domain modeling each day of my journey in hopes to become a qualified expert on the matter. 

I couldn't have been more naive about what I was trying to do. Domain modeling is a hard task to do well. It involves a domain, usually the business problem you are solving, and the idea is that if you can isolate that domain from everything else and properly model it, you will develop an application that is robust and amenable to future changes. The future changes will probably even come naturally if you are doing it right. The problem, for my situation at least, is that you need an actual business problem for the process of domain-driven design, DDD, to work. At the center of DDD is the idea of a ubiquitous language that developers, project managers, and business owners all speak. This way a widget doesn't mean one thing to someone and another thing to a developer, and the developer has less of a chance to develop something that is "wrong" just from a misunderstanding in language. I hope to one day re-read and apply Mr. Evan's theories and practices, but they weren't going to work for me.

I had no project managers, developers, or business owners; it was just me. So, there was no need to develop a ubiquitous language to facilitate communication between parties. I also didn't really have a domain problem to start with. I had no current business proposition, no competitors, no model to imitate. All I had was a desire to learn new programming languages and a sense that I wanted to help people plan and carry out their own sabbaticals. The software would be focused on that goal; however, it's not a very concrete goal since the activities and necessary planning for a sabbatical can mean a lot of different things to a lot of different people.

I was lucky enough to read the end of chapter four of the DDD book where Mr. Evans declares a "Smart UI Anti-pattern." He contrasts DDD and what he is about to lay out with a simpler approach for simpler applications. I almost felt like he was putting in that section just for snotty-nosed kids like me who were trying to obtain their "big boy" developer pants and talk the talk with the seasoned pros. Evans basically says that there are whole scores of projects where DDD and its principles won't help the development of an application. Furthermore, following DDD in those examples will actually probably harm the project and lead to an unnecessary level of sophistication for a simple application. Instead, he argues that in those cases focus on business rules should be put in the UI. Separate UIs will have different logic and if they need replaced or changed in the future, simply swap out the whole UI for a new one. Rather than fail at DDD and waste time reading the rest of his book, I took Evans advice and focused on the screens.

It's All About that Screen...bout that Screen

After I thought about it for a second, it seemed so clear. Draw out the user interaction and then you will know what to start building. It will be wrong, but that's okay. You will learn in the process and refactor to correct any mistakes or discrepancies. I had always been a little miffed when I got a design to implement as a developer without really being involved in the conversation, but I can now see why that was the practical first step most of the time.

While I think involving the developer in more communication is usually a good idea, it can also be a waste of time if the client is unclear on what they are asking to be built. Of course, they are always unsure to some degree, and prototypes help to iron out details. Developing prototypes is definitely a skill that I don't think I possess. Once I knew I wanted to focus on prototyping, a quick Google search had me drowning in potential tools that all had widgets and learning curves that I didn't like. As with programming languages and frameworks, everyone has their opinion on which prototyping tool to use and why other options suck.

I spent a brief amount of time looking into these diatribes but quickly saw how un-useful searching for a perfect prototyping tool was. Even if I were to find the most perfect tool to use, I would then have to learn the lingo of how to use it on top of learning and using new programming languages and frameworks. Since I don't plan on becoming a UI/UX expert anytime soon, I didn't see the point of learning a system that wouldn't be that much more helpful than a pen and paper and would still force me to translate the out put into front-end code anyway. If I was working in a team or with clients, I might have spent more time on this; but if you are working alone, you might as well move on... 

The Pen is Mightier than the Prototyping Tool

So, I simply used a pen and paper...well, at least the technical equivalent to a pen and paper in 2015; that is the S-pen and Samsung Galaxy Note 4. I recently purchased this smart phone after my two year contract was up, and the S-pen was definitely something that drew me to the smartphone. I honestly wanted to get a Note Edge with the second curved display, but Verizon was cool enough to wait until after I purchased my Note 4 to release the Note Edge in the US. Thanks Verizon! Anyway, the Note 4 is an excellent phone for many reasons, but I in my first month of use, I rarely had moments where I would pull out the S-pen.

The S-pen stylus makes it super easy to select something on your phone that your fat fingers are having a hard time pinpointing. I did use it a few times when the website I was browsing was not mobile-optimized and the menu links were very hard to click on. Other than that, the S-pen stayed docked inside my Note 4...that is until I wanted to prototype some screens. The minute I had a new idea it was easy to pull out my S-pen, open the S Note app, and start doodling away.

There are many sketching apps I suppose you can get in the Google Play store, but I went with Samsung's app because it was...just there. Samsung has been accredited with putting a lot of bloat on its phones, and the Note 4 is no different in that aspect, but I find a lot of the bloat-ware useful like the S Note app. The best part, in my opinion, is that you are forced to think in a mobile-first manner when sketching out screens on a mobile phone. I think most of the prototyping tools I encountered in my brief search above defaulted to the desktop view when you first entered them. In a day and age where responsive web design and mobile-first are the norms, it's strange to think that prototyping tools might be hindering an optimal experience by starting you in a desktop view. However, if you prototype on a smartphone with a stylus, like my Note 4, it's impossible for you to not think mobile-first, and I hope your applications benefit from this enforced perspective.  

From Screen to Action

In a matter of minutes, I had drawn several screens that linked together in a logical sequence. This exercise dramatically helped me envision what I actually had to build for my sabbatical application. Instead of starting with abstract and potentially misleading domain models, I started my coding with rough screenshots of how a user might interact with my application. I didn't necessarily go whole hog with the prototyping/sketching screens approach though, as my initial screens were still pretty ambiguous as to what they were trying to accomplish and what models would support their logic. 

So, I ended up switching to building a subset, feature if you will, action that would be incorporated in my application. I knew I wanted to do something with screen scraping data from various websites and turning my application into a sort of opinionated spreadsheet. Something that knew what each value was, why it was important, and what you wanted to happen before the application drew your attention towards action.

I had heard that Ryan Air and Easy Jet were the two top cheap flight operators for traveling across Europe, and after a few searches that did seem to be the case. I suddenly had a thought that it would be cool if my application could tell me the cheapest route for going around Europe from a list of cities I wanted to visit. Since I didn't the order in which I visited my list of cities, why not create a screen scarping algorithm that could tell me if there was a particular route sequence that I should be paying attention to. I would hope then that I could extrapolate from that concrete algorithm something more abstract that I could generalize as a tool to use for traveling around the world. 

For the screen scraping part of my application, I decided to use Capybara and the Selenium web driver. Capybara's default driver apparently is only good for rack applications and not so much for visiting external sites like I needed to do in this case. Although it's odd to see Firefox opening up windows and automatically doing my bidding, my real concern is how to do the final screen scraping with a headless web driver, if possible. If a headed web driver is needed, then I will have to figure out some way to have my application perform the screen scraping locally on the user/client rather than the server.

But...first things first, I have to develop my screen scraping algorithm. More on that to come in the future.