The calculator challenge: resolved

A couple of weeks ago, I shared an exercise I used to evaluate OO design skills on recruiting interviews. I got some interesting feedback from different people out there. Today I want to share an answer. As someone pointed out, this is a very simple problem, but even so, I could find no one to solve this. Not even one. In my experience, the moment the interview went on another direction than a CRUD exercise the developer find himself lost. So let’s review the problem statement:

Design a program that given a string such as “(1+2)/3*4” returns the correct result.

Finding the abstractions

So we need an object that evaluates an expression and returns a numeric value. Straightforward.

However, having an object that evaluates every single type of operation present in the expression is a violation of the single responsibility principle. The solution? Divide and conquer. Let’s create an object for each operation.

Now, all the calculator must do is to pass the expression to every operation object. Even when the message it’s called Evaluate, the return value from each operation object should be the expression with the values in place so that it can be passed to the next operation object. To extend the calculator capabilities all that’s needed is to add another operation object. This can easily be accomplished using an interface implemented by all the operation objects.

Focusing on the what, not how

I want to bring your attention to the fact that so far we haven’t discussed how this objects are going to evaluate the relevant bits of the expression. We don’t even have the data types on the messages (is expression a string or an object?) To me this is the hallmark of an experienced OO developer: the ability to focus on the big picture and ignore the little details until needed. This is called abstraction. Traditionally we are trained to start thinking on an algorithmic way, thinking of every minute detail. It takes some time and effort to start focusing on the what and leave the how to later. Going this way, we can use another technique to design the objects internals (the how, the implementation details) such as TDD. For the record, I’d probably use a regex to match the arithmetic sign, extract the values, execute the operation and replace the value back into the expression.

The next challenge

So, if you ever were on an interview with me, this is the answer that you probably almost found. Anyway, I have another challenge here: Can you identify the design patterns used in this solution? Which patterns would you use to improve it?

The phoenix project review

I just finished reading The Phoenix Project, a book in the style of Eliyahu M. Goldratt’s The Goal. I’ll try to cover the main ideas without going into too much detail. If there’s interest I can dig more into a specific theme or idea.

The Premise

Probably the main idea is that the software construction process is alike to a manufacturing plant line of production. If you have never been into the manufacturing process there are some concepts that you need to understand before going further.

Bill of materials

The Bill of Materials (or BOM) is a list that contains all the components needed to create a product, all the way down to the raw materials. An example could look something like:

  • Product X
    • Component 1
      • Sub Component 1
      • Sub Component 2
        • Component 3
    • Component 2
      • Sub Component 3
        • Raw Material 1
        • Raw Material 2
    • Component 3
      • Raw Material 3
      • Sub Component 4

The BOM also includes the amount of each component or material needed.

Work Center

The work center as it name implies is a specific place where a specific activity takes place. Ie. in an automobile manufacturing plant, there could be a work center where the doors are attached, another where the motor is inserted in the vehicle and another one where it’s painted. In the phoenix project there are 4 elements in any work center: the machine, the man, the method and the measures. A work center also has a wait time: the time it takes to start working on an assigned task. The more tasks are pending to be executed by a work center, the more wait time it’ll take to start working in the latest assigned task. This is represented by the following formula:

Wait Time = % busy / % idle

Bill of Resources

The Bill of Resources = BOM + Work centers + routing, where routing specifies which work centers are needed to finish a product and in which order. Basically it list all the steps needed to complete a product.

The software feature release as a production line

According to the book, there are some work centers where certain activities take place when we are releasing a software feature/patch/update. Consider the following example:

Code -> Build -> Test -> Package -> Release -> Configure -> Monitor

These are all activities that take place on its own environment, and that need its own people, with its own techniques and procedures and its own metrics.

The 4 types of work

According to the book there 4 types of work:

  1. Business Projects.- These are business initiatives to reach the company goals.
  2. Internal IT Projects.- These are mostly infrastructure improvements that may or may not be derived from Business Projects.
  3. Changes.- Different activities derived from Business and Internal IT projects that can severely affect the production systems.
  4. Unplanned work / Recovery work.- Production bugs fixing

The idea here is to find where the unplanned work it’s coming from and fix the source ASAP, while accelerating the other types of work that really add value to the business. To do this the book proposes 3 improvement phases called The 3 Ways.

The 3 Ways

The First Way

The first way focus on accelerating the types of work that add value to the business. It does this by streamlining the work flow of the work centers, using techniques such as those from lean manufacturing: identifying value streams and using kanban boards, among others, limit WIP and the theory of constraints: identifying bottle necks and exploit them to the maximum. It relies on mechanisms such as continues build, integration and deployment, automating the creation of environments on demand (using tools such as Vagrant and Docker) and so on.

The Second Way

The second way focus on getting rid of the unplanned work ASAP. It does this by creating faster feedback loops from the work centers down the stream back to the previous control work center until it reach the responsible work center. This allow detection of anomalies and errors earlier int the deployment cycle. It uses techniques such as improvement katas, creating shared goals between departments and creating a production telemetry to make sure that 1) the systems are working fine, 2) the environments are working fine and 3) customer goals are being met.

The Third Way

The third way focus on creating a culture that fosters 1) continual experimentation and 2) repetition and practice. These are requirements to Innovation and Quality which are a must for any business survival these days.

Aligning IT to the business Goals

One of the things that happens a lot to us tech guys, is that we get so focused on technology that we paid less attention to the business it serves. We simply choose to learn technology over domain. This is comprehensible since tech skills are more transferable than domain knowledge for us. But one of the points remarked on the book it’s that first we must understand the goals of the business we are working for. This will give us the criteria to discriminate which projects and changes are important and must receive most of our resources. To me this sounds like the 80/20 rule. Only aligning to the business goals, can IT become a real advantage to the business.

Impressions on the book

I found the book very easy to read. While not as captivating as The Goal, the story line and writing styling weren’t boring. After reading the whole novel, I found some food for thought in the Phoenix Project Resource Guide and later chapters. The DevOps umbrella comprises a lot of tools and practices and Gene Kim and friends have done a very good job organizing those in the three ways. I very much recommending reading the book.

The calculator challenge

It was another normal day on the IT department at a big manufacturing company I was working back then when my boss ask me to see him on his office. It turns out we were starting a new project and needed some extra hands. My boss wanted me to interview potential candidates. It was my first time as a recruiter and a fun experience. I was tasked with finding some experienced OO developers, which can be tricky to say the least. One night it occurred to me that the best way to gauge a developers OO skills are to evaluate his/her design and thinking skills: it’s faster, and you cannot cheat on it (googling it or whatever). That’s how I came up with the calculator challenge.

The problem

Design a program that given a string such as “(1+2)/3*4” returns the correct result. It has to be extensible, meaning that you can add further operations without having to modify the structure of the program to do so (open/closed principle).

I didn’t require the developers to code such a program, just to design it and explain it. It shouldn’t be that hard for a seasoned OO developer to complete the design, but for the guys I interviewed back then, it was puzzling. They could not figure out the SQL to do that. Some other suggested using web services, but no one could ever solve it. My coworker, who was in charge of evaluating the SQL part told me that he wasn’t sure he could do it either. I never told him the answer 😛

So, how would you solve this? Leave your answer in the comments.

OOP: Stop thinking about the data flow!

The main problem with the OO analysis that I’ve seen comes from the inability to leave some thinking patterns that are very routed into our analysis practice. We are animals of habit and while creating them may take at least 3 weeks, getting rid of them it’s usually harder. In this post i would like to suggest some tips to help you change your analysis approach for an OO system.

Forget everything you know

I have this spherical puzzle. Well actually it’s my daughter’s. I brought it to the office and so far only 2 of my companions have been able to resolve it. The skillset required to solve this kind of puzzle it’s very different that the one required to solve a traditional puzzle. Besides considering the shapes that now are 3d, you have an additional restriction on the order the pieces are put together. This alone requires a new thinking process, a new paradigm to try to figure out the solution. If you are a good puzzle solver your old skills are more likely to get in the way than not. It’s the same with this post. I’m just saying, keep an open mind to it.

Messages are not data

Consider the following case: you have to notify whenever a customer status change. This may be whenever a customer is new, or is deleted.

public enum CustomerStatus {New, Removed}

public class CustomerEvent
    public string Id {get; set;}
    public string CustomerStatus Status {get; set;}

public class CustomerEvents
    public event EventHandler<CustomerStatus> OnChanged;

public void main ()
    CustomerEvents events = new CustomerEvents();
    events.OnChanged += (s,e) =>{
            case New:
            case Removed:


Take 5 minutes before looking the snippet below. Can you spot what’s wrong with this code?

public class CustomerEvent
    public string Id {get; set;}

public class CustomerEvents
    public event EventHandler<CustomerStatus> OnNew;
    public event EventHandler<CustomerStatus> OnDeleted;

public void main ()
    CustomerEvents events = new CustomerEvents();
    events.OnNew += (s,e) =>{...}
    events.OnDeleted += (s,e) =>{...}


“So?” – you may say – “what’s the big deal? It’s the same data, just exposed on a different way”. Well, yeah, it’s the same data, but these are 2 different messages. And that’s and important difference. A message is more than just a way to pass data. It’s an explicit request, we may supply some data to help accomplish the request but that’s just it. What’s important it’s the meaning of the message, the thing we are requesting.

If you want to code in an OO paradigm you need to start thinking in that paradigm: start focusing on the message flow, not the data flow.

Messages, messages everywhere

As mentioned before, an OO program can be better understood if we start with the dynamic side of the application. This means, the objects and the messages sent among them. A good starting point is to take a user story and instead of trying to do a flowchart use a sequence diagram. Try it. Even if you already have a flowchart in place try it.  Some things to keep on mind while doing it:

  1. Try to make your messages as explicit as possible.
  2. Forget about the implementation problems that may arise. Dictate your messages based only on your needs and nothing else.
  3. Avoid the need to figure out where the data contained in the messages, if any, comes from or what it looks like.
  4. Stop thinking on functions that receive data and start thinking on messages sent from one object to another.
  5. Try avoiding getters and setters as much as possible. This will force you to stop thinking of objects as data bags/tables/structs and make you think of them as things that can respond to messages. Instead of asking them for data have them doing whatever you were planning to do with that data in the first place.
  6. Avoid the use of static functions in any other way than as factory methods.
  7. Use interfaces for any object that may change a lot, or to encapsulate a particular way of doing things (algorithm).

As time goes on if you keep practicing you’ll find out that the real abstraction is on the messages. Maybe this is what Alan Kay was thinking of when he said that he should have coined the term “message oriented programming” instead of “object oriented programming”. When you have a set of messages, you can just switch the objects and as long as they can respond to them (the messages), your program will continue to work. Your messages are still in place, your objects are the ones that are replaceable.

Another example

Just consider the following c# code:

string yourName = "sam";
var greet = String.Format("hello {0}!", yourName);

The idea in this is calling a function, passing some data to it and expect the result. The static method “Format” uses the class as a module, a container for functions. The OO way of thinking would be to send a Format message to the string object requesting it to do the operation:

string yourName = "sam";
var greet = "hello {0}!".DisplayOnPlaceholders(yourName);

Here the message DisplayOnPlaceholders(yourName) it’s more explicit than just Format. This allows any developer to understand what it does without having to check it’s code to figure it out. You can mimic some of this behavior using extension methods. There’s a huge library on Check it out.

Closing words

Some of you maybe find this stuff absurd. But if you code in any of the multiparadigm languages out there and want to get better at your OO skills without learning smalltalk, I strongly suggest that you follow this ideas in as much as possible, at least while you’re getting the hang of it (that is until you start thinking of case objects instead of switch statements). Especially if you come from the .net area (like myself). And enjoy coding 😉

The UML class diagram: you are probably using it wrong

As I have mentioned before I learned VB6 with the help of a book. The book introduced me to the basic control flow structures and then to databases as a form of storage. It touched a little on the relational theory and how the structure of the database would affect the structure of the data as represented in the software and therefore the need to start modeling the database before anything else. So, for years I followed that pattern. The data model became my de facto starting point. Even when I learned C++ and Java, 2 OOP languages, my analysis approach remained the same. For a long time…

The confusion

A common approach to database design is to use the entity relationship diagram. It shows tables and the way these are related to each other. It’s pretty simple actually and easy to reason about. I believe that’s the reason for their popularity. So when I was starting into OOP (as opposed to only learning OOP languages) and I was introduced to the Class diagram I immediately mapped it to the ER diagram and hence the thinking behind it. So for a long time I would still doing data modeling, but instead of using an ER diagram I was now using a Class diagram.

The UML diagrams classification

Suppose you are tasked with creating a robotic arm to crack eggs open. Where would you start?

Probably you would start by trying to figure out the movements used to crack an egg open. You would do this by looking an expert and maybe trying to learn the trick yourself. Then you would start thinking how to replicate that movement. This may lead you to identify a key components and the interactions between them. You may make some sketches. And from here you probably would start experimenting with different configurations and maybe tweaking the pieces a little bit until your experiment is successful. And then you would create some blueprints so some one else can build your piece of art anytime.

Software development is not different.

Static diagrams

Just like the blueprints for creating a robotic arm, the code we write is the blueprint used by the computer to create the software artifacts of our application. This static aspect of software defines the structure of the components that are going to be created and the UML static diagrams such as class diagrams are used to model this.

Dynamic diagrams

Like the interaction between the different parts of a robotic arm, the UML dynamic diagrams describe the interaction between parts of the software. This is dictated by the messages send back and forth between objects.

Relational vs OOP

So while the ER diagram it’s used to model the database structure, the class diagram it’s used to model the application structure. One is for data storage and the other for the application code. More often than not, the structure used to store data in relational databases is not the best for an OOP application. The opposite is also true. This is due to the approach taken for each paradigm: the relational school makes emphasis on avoiding data repetition using a technique called normalization, while the OOP side stands for avoiding code repetition using inheritance, composition and other techniques. This difference is known as object-relational impedance mismatch.

Spotting the differences

While at a glance the ER and Class diagram look similar the process by which each it’s created it’s very different.

The ER construction process

The process to the ER diagram is like creating the blueprints for construction. Since it’s not so easy to change a relational database once you start putting data on it, it’s better to make it right from the start. To this end we identify the entities on our domain space (the business industry) and then try to identify the relevant information for each from the data flow of the application. An a lot of time we guess some of the information that may be used in the future (at least I have).

The Class diagram construction process

On the other side the Class diagram construction process is more like the construction of a robotic arm: it takes a lot of iterations and you start by modeling (sketching) the mechanisms (dynamic aspects) and then do a lot of experimentation until you get it right. I often use an interaction diagram to model how the objects (not classes) are going to interact. When you have a set of objects and a set of messages send between those objects, the Class diagram is almost a natural step: you already know how those pieces interact, now just have to figure out how they are to be assembled together.

Using the class diagram: a better way

As Allen Hollub points out, we do object oriented programming, no class oriented programming. Classes are just that, classes of objects, or in other words, groups of objects that share some traits. You can only start to classify objects when you already have a bunch of them.

  1. Start with the dynamic side of things: find your key objects and the messages they send to each other.
  2. Experiment using a testing framework so you can see if it’s feasible in the shortest possibly time. Adjust as necessary.
  3. Create a Class diagram and start sketching everything you got so far, trying to identify and remove any duplicated code and to identify and decouple the parts that may change often than the rest. Don’t let the worries about how you are going to store your data affect your Class diagram. Try to delay dealing with persistence as much as possible.
  4. Only after you have a set of stable objects use the class diagram to aid you in the creation of your ER diagram. This is not a 1:1 mapping, don’t be afraid to optimize your ER diagram to your RDBMS.
  5. Use your class diagram to explain the structure of your system to other developers, and the interaction diagram to explain, well, the interactions between your objects. They can serve you to demonstrate the implementation of certain patterns in your application. After all, diagrams are all about communicating ideas.


A tale of 2 paradigms: how curly braces can confuse young programmers

I was like 15 when I learned programming. VB6 was my first experiment. Later on I went on learning C++ on university. And C# on my first work. Then one day I came across C (a flavor known as Dynamic C used to program rabbit micro controllers) on one of my jobs. Once I grasped the concepts on VB6 I never really had a hard time jumping from one language to another. I could easily move the concepts from language to language. And then I learned smalltalk. Somehow it felt (and sometimes still feel) like hitting a wall. I decided to learn that because I read somewhere that if you wanted to truly master OOP you need to give that a shot. Turns out that is true.

It’s all in the mind.

There are several programming paradigms out there, and while OOP is probably one of the most abused words in the technology arena, I’ve found that is also one of the most misunderstood paradigms. At least in my experience. I considered myself a decent OO developer and even had some cool projects listed on my resume. Why then, did I had problems when starting with smalltalk?

The paradigm bridge

As I continue to find code that’s supposedly OO using procedural techniques, often wonder how is it that we don’t realize this. Even worse, we still believe that we are writing OO code and try to apply OO design patterns which often leads to convoluted code. To explain my theory behind this i would like to take a walk through history.

Imperative programming

In the beginning there were this monolithic creatures that walked over the hardware. They view of the world was a simple one: you start on line 1 and then continue executing line after line until you find a GOTO instruction, then you jump to whatever the GOTO points you to. On each line you have to explicitly command the computer on how to do whatever you want. This paradigm is called imperative programming. Even in this day and age you can find some people that still writes code like this for line of business applications (I have).

Procedural programming

At some point in time, Edsger Dijkstra wrote a letter explaining how this instruction (GOTO) was making code harder to understand and maintain. I’m not sure if this was what lead to the notion of structured programming but the concept certainly gained popularity around that time. When applied to imperative programming we got what’s called procedural programming. This is nothing more than a decomposition of an imperative program into a series of smaller programs, procedures, which are called from the main program. With this came a lot of new control flow structures like switch, while and for, to replace GOTO statements. One of the most representatives languages of this paradigm is C.

Object oriented programming

On the 1970’s Alan Kay and the people at Xerox Palo Alto Research Center came out with smalltalk. I was a very concise language (all of the smalltalk reserved words can be written down in 1 card) which ran on a virtual machine and introduced a new paradigm: Object oriented programming. It basically stated that any program could be represented as a series of objects, little programs which communicate with each other sending messages. This was so easy to reason and write that using smalltalk many kids created impressive stuff, even for today.

Mix and match

As OOP started to gain popularity, some people tried to implement the OOP paradigm on languages that were already familiar to a lot of people. So C being wildly popular, became the default choice for this experimentation. The results are C++ and Objective C. I believe that the idea was to reuse the familiar syntax on the new paradigm. And it looks like that was the same reasoning behind Java and C#.

Drinking all in the same glass.

The problem with this, IMO, is the way this languages are taught. You can do the experiment yourself: look for a course on C++, Java or C# and look at the contents table. Most of the time they start with all of the structured programming keywords (the ones inherited from C) before even touching the notion of an object. Most of the courses out there are effectively teaching structured programming and then try to introduce the student to OOP without explicitly telling him. These are 2 different paradigms that require a different mindset. The ‘switch’ keyword concept is not even present in the OO paradigm. It is not needed. Yet the student just learned it as part of the same language so he assumes that it’s safe to use it. Even worse he assumes that’s the way to go. He is having 2 different drinks in the same glass. How can we expect him to distinguish between one paradigm and the other?

Learning and moving forward

Looking back I now understand that before smalltalk I was using an structured programming approach, with some OO features. This limits the benefits of using OO. Learning smalltalk force me to finally switch to a completely OO mindset, which is awesome. I’m still learning, and feels like there’s still a long way to go, but hey, at least now I’m aware of it.

Alternatives any one?

I’ve been thinking on alternative teaching approaches to overcome this problem but still don’t have anything solid. How would you solve this matter?


TDD Styles

There are 2 schools of thought in the TDD space: top down and bottom up, the former becoming increasingly popular, while the latter it’s the classical approach used to teach.

Given that a developer is working on an Object Oriented paradigm, if he chooses the bottom up approach he’ll start writing unit tests for the objects he needs to complete the requested feature. The catch here it’s finding which objects are these. This may lead to some refactoring and experimentation until the right set is defined.

Top down approach

A response to the problems above it’s to start writing tests at a higher level of abstraction. So now instead of defining the object interface we start by designing the component interface or even the complete application API. This gives context and help define how the objects are gonna communicate and which messages they should understand.


BDD it’s a style to help the developer to understand that he is designing not testing and provides a concise language that both, the business and the development team can use. It’s called Gherkin and has several artifacts. The following example shows the format.

1: Feature: Some terse yet descriptive text of what is desired

2:   Textual description of the business value of this feature

3:   Business rules that govern the scope of the feature

4:   Any additional information that will make the feature easier to understand


6:   Scenario: Some determinable business situation

7:     Given some precondition

8:       And some other precondition

9:     When some action by the actor

10:       And some other action

11:       And yet another action

12:     Then some testable outcome is achieved

13:       And something else we can check happens too


15:   Scenario: A different situation

16:       ...

A concrete example:

Feature: Serve coffee

Coffee should not be served until paid for

Coffee should not be served until the button has been pressed

If there is no coffee left, then money should be refunded


Scenario: Buy last coffee

Given there are 1 coffees left in the machine

And I have deposited 1$

When I press the coffee button

Then I should be served a coffee

These Gherkin file it’s parsed and some code templates generated from it. This code templates are the placeholders for the testing framework and the start point for the developer to begin coding.

Just enough design

Another approach to work around the limitations of the bottom up approach is to do just enough up front design typically using UML sketches. This allows the development team to brainstorm different designs in front of a whiteboard. The purpose of these designs is to identify the early players of a use case. The implementation is then left to the TDD practice. Common tools are UML’s use case, activity and interaction diagram. I have described this approach before.


A few words on the practice of TDD

Whether you choose a top or bottom approach the important thing to keep in mind is that you are not writing tests, you are specifying the way you want the code to be used, even before that code exist. This is more of an experiment than a testing exercise. The idea is to find the abstractions and messages needed to resolve the problem at hand without getting distracted by implementation details such as DB, UI or web services.

TDD and the “Add Value” premise

Discovering what brings value

There are only 2 kinds of code: the one that brings value to the customer, and the one that doesn’t. I’ll call the former domain code and the latter plumbing code. But what does this mean?

Domain code

In simple terms if it’s not in the business jargon, it’s not domain code. That is, all of the business concepts and the rules that dictate how they relate to each other, the services provided by the business to its clients, the actions taken on specific situations (procedures) are all part of the business domain and automating these (completely or partial) are the things that help the business to increment revenue, diminish costs, accelerate the procedures execution and take better decisions. Otherwise it doesn’t add value to the business.

Plumbing code

This is the kind of code that doesn’t directly add value to the business. Is mostly comprised of technical aspects such as the database, software architecture, reporting technology, technology stack, frameworks and so on. It is necessary for an information system to run, but it is not the reason why the system was created in the first place.

The “egg or chicken first” paradox

Common sense dictates that the things that are most important to the business are to be put first. That is that a development team should make sure that the business policies, rules and logic are correctly implemented in the code before anything else. The common practice however, is a different story. That is because the developer usually needs a minimum amount of plumbing code to test if a business rule is working as expected. Consider the case when a developer has to test a simple rule: you can’t get more money from a back account than available. To test this the developer may start creating a BankAccount table, then writing the code for the rule, then creating a test program to exercise that code. And then he would have to add code for transient fault handling in case the database connection fails. So writing the code that adds value (domain code) it’s just a tiny fraction from the whole operation. Most of the actions are about setting up the infrastructure. Even more, a lot of developers take this all the way up to creating an API or UI. This just makes harder to test the code related to the rule, since now there are several points where something may go wrong. So now in order to know if the rule is correctly implemented, the developer has to put an end to end application that may have to be modified in the event that the domain code needs to be rewritten. So which is first: domain or plumbing code? 

Defining what’s to be done

TDD change the focus from the plumbing code back to the domain code. It makes this by forcing the developer to create functional specifications in the form of tests and then create code to fulfill the specification’s expectations.

On a typical development project, a lot of the initial analysis goes into the plumbing code: database, frameworks, operative systems, hardware and so on. On the other hand, the business idea of what the system is supposed to do is subject to evolve as the developers and the business discover the requirements and needs. Unfortunately, a lot of time the developers don’t dig into it until later on, when all the technology stack has been decided. This creates a situation where the domain code is now restricted by the technology stack limitations.

TDD reverses this situation. By having the developers to create the specifications first, they find themselves in the need to understand better what’s the expected outcome for a piece of software. Taking back our previous example, what’s supposed to happen when the bank account has not enough money to fulfill a withdraw operation? An exception? Returns a message? Should that be a string or a structure of sorts? Or a function (closure)? Should these be logged? Should the account owner be instructed to go through some sort of procedure (like a loan)? To answer these questions, the developer has to understand what does the business expect to happen. This will lead him to go back to the business and make questions until he understands enough to continue. This process usually happens on any development project, especially if they’re following an agile methodology, but the use of TDD greatly accelerates it. It allows the development team not only to write the software in the right way, but to help the business to decide if it’s the right thing.

So are you ready to jump in?

Code vs Database: hosting the business logic

Back in 2008 I began working for a startup that had a product for government administration. The thing with the government space it’s that they invest a lot in IT infrastructure: licenses, hardware, custom software and so. This makes it almost impossible to pitch a new system if it can’t leverage what the institution already has. Over time we came to have several customers using different databases. How did we manage to deploy the system to customers using Oracle, MS SQL and pretty much almost any database as a data store? As I have been on different projects since then, whenever I found a restriction imposed by a technology (like a DB system) I found myself asking this question once again.

Achieving database system independence

Government can be a complex beast, with all it’s regulations and rules. It was challenging to make the product flexible enough so it could be easily adapted to a new customer requirement’s. Heck it even had a scripting engine! But looking back I believe that this was possible thanks to 2 things: using an ORM and putting no logic on the DB.

By using an ORM we achieved data type representation independence. That is, all the data needed by the system is represented by the objects in the system regardless of how they are stored. This gave us the liberty to switch from one db technology to another without having to change the code. All we had to deal with was changing the db provider, who had the knowledge to serialize the objects to each DB. We could write our own provider to save to files, had we wanted to.

Since the beginning it was clear to us that having logic hosted in the DB was not a good idea. Had we gone that route, we would had a hard time porting the system from a DB to another. It’s also harder to test. The funny thing is that a lot of developers still follow this practice. Even more, they embrace it!

Encapsulation as a system attribute

I have talked about encapsulation as a code attribute before. However the same principle can be applied to a system as a whole. By having a data representation that is independent of any external technology, we can reduce the impact of external forces (like changing the data storage or presentation technology). That’s the purpose of the so many architectural guides out there: to have the logic resilient to changes from the outside. In my experience this is a natural effect when following this same principle at the object level.

However having the business logic in more than one layer (presentation, data or anything else) always lead to code that is harder to maintain and test. Define a layer that holds your business logic (domain layer) and put all your business rules and logic in there. In other words encapsulate the business logic in a single layer.

A word about SQL

An interesting fact that makes me curious is that the standard SQL specification has no control flow structures. That is why is so hard to move logic from a DB system to another: each one implements it’s own way. But why deal with this when you can use a general purpose language that implements all of this from the get go? If the ANSI SQL does not implement it, why force it?

Abstraction levels

“Abstraction” is the action of simplifying something up to the most important traits.

I like to explain it as a sort of google maps but instead of zooming in and out of a world map you are exploring a model. Just as with google maps we have several views with different levels of detail. We call these abstraction levels. In the context of designing a system this is a useful tool. So using google maps as a metaphor I want to share a personal way to see the abstraction levels on a system.

Abstraction Level Purpose
10,000 ft view Overview of all the actions that can be done on the system
8000 ft view Overview of the way a user executes the actions on the system (UI)
6000 ft view Overview of the steps needed to carry on the action being requested
4000 ft view Overview of the objects that carry on the action being requested
Ground lvl Implementation details of the object

For the sake of this discussion i’ll leave the 8000 ft. view out.

10,000 ft. view

This level can be represented on several ways. My favorite one is using a use case diagram.

The other way I find absolutely useful is using BDD’s “feature” artifact.

 Feature: Create Loan
 In order to pay for a necessary item
 As a customer with no cash at hand
 I want to get a loan

The nice thing about this is that it also expresses the user’s objective.

The 6000 ft. view

In this view we peek inside the actions of the system (use case, feature). Typically, an action has more than one execution path: the default (expected) path and one or more alternatives. This view can be explored using an Activity Diagram.
This view can also be explored using BDD’s “scenario” artifact.

 Scenario: Apply for a loan while having an open loan with a different provider
 Given I already have an account on the site
 And I have an open loan on with a different provider
 When I try to create a new loan
 Then I'll see a message saying "Sorry you can't open a new loan if you already have one open"

Scenario: Apply for a loan with an amount exceding the maximum allowed by the state
 Given I already have an account on the site
 When I try to create a new loan
 And the amount requested exceeds the maximum allowed by the state I live in
 Then I'll see a message saying "Sorry the amount you applied for exceeds the amount allowed by the state"

Scenario: Get a loan
 Given I already have an account on the site
 And I have no open loan
 When I try to create a new loan
 Then the loan will be created

The 4000 ft. view

If the 6000 ft. view allows us to peek into the action, showing us the several execution paths, then the 4000 ft. view it’s all about peeking into the execution paths and the way they are carried along by the business objects. I usually use interactions diagrams on this level.

As you can see this diagram focus solely on the business objects, their responsibilities and the interactions amongst them in order to fulfill the action objectives. In this particular example I’m including 2 paths, as you can see from the lines that return to the Customer actor. I could have one for each scenario.
The point here is that these methods are just loosely defined, still waiting to be fleshed out. This is where TDD comes in. You can create a test declaring what you expect the behavior to be and then code out this particular method, isolating any external dependency.


I originally depicted this while trying to explain that TDD and BDD are basically the same thing just on a different abstraction level.
So if you create tests for anything on the 4000 ft. view before any code is in place, then it’s called TDD, whereas if it’s for anything above that abstraction level, it’s called BDD.

Let me know your thoughts.