A Blog about Business, Enterprise Architecture and Software Design by the Founders of ZenModeler

Domain-Driven-Design Distillation: Support, Generic and Core Domain

Distillation is a procedure whereby the components of a mixture are separated in order to extract the various ingredients, particularly the most valuable one: the “heart” of the distillate.

The domain represents knowledge of the subject matter; the work of a company, in which its employees are engaged. Distillation, a thought-process stemming from Domain-Driven Design, enables us to classify the domain of a company as belonging to one of three categories and we can do it without alcohol! The chemical analogy is enlightening because it focuses on isolation of the component that is most valuable for the company: the “core domain”.

What is the Core Domain?

The core domain is the part of the domain most closely associated with the strategy of the company.

Definition of Strategy

I offer the following definition for the strategy of a company:

Strategy refers to objectives as a function of environment and available resources, followed by the allocation of these resources, in order to create value for customers while simultaneously creating profit for the company and its employees.

A few remarks concerning this definition:

  • A well-defined strategy must outline the priorities around which employees concentrate their time and effort
  • Profit certainly means financial gain, but it also includes job satisfaction and career advancement for the employees, with similar benefits for the customers. “Don’t be evil,” as they say.
  • Strategy is dynamic; it is changing or will change over time because the environment is changing, and with it the objectives

What is a Support Domain?

A support domain is a part of the domain that indirectly supports the core domain without actually belonging to it.

Typically, this is a thing that everyone needs, yet no one wants to pay for. The reason is that the value added, taken in isolation, is weak. For example, bookkeeping is indispensable in many banking activities, but no one wants to pay for it.

What is a Generic Domain?

A generic domain is one that is universally well-known, without any need for specialization in the core domain.

Some classic examples are accounting, human resources, and project management. These domains are widely known, sometimes even including their various sub-fields. In technical terms, this could for instance be an optimization tool for finding a path in a graph (and many problems, I might add, can be boiled down to a graph). Options to consider here, naturally, would be open source, software packages, outsourced development, and, lastly, in-house development. In this latter case, it would be pertinent to ask the following questions: Is it worth my while to write the software? Why not purchase it off-the-shelf? Why not outsource it?

A Few Examples

Amazon and eBay Rankings

Amazon and eBay both have ranking functionality integrated into their sites; I am referring to the famous “stars.” On Amazon, ranking is associated with a product, such as books or CDs. On eBay, ranking is associated with a seller. In both cases, the domain is virtually the same: an evaluation and a comment, a ranking of these evaluations and an average.

Nevertheless, Amazon and eBay have different business models. For Amazon, it is to sell new products, often subcontracted to professional third-party merchants. For eBay, the basic business model is the sale between individuals; in this domain, a key element, and a strategic one, is the level of confidence between buyer and seller. Ranking therefore acquires a strategic interest for eBay because it forms a part of its strategy of establishing maximum confidence between customers. This is not the case for Amazon. Ranking is therefore part of eBay’s core domain; for Amazon, it belongs to the support domain because rather than playing a direct role in Amazon’s strategy, it is only a support function.

Still considering the same sector of activity, Amazon’s logistic domain is probably within the core domain because rapid and efficient delivery is a strategic advantage.

The Banking Sector

In the banking sector, functions related to bank accounts (debit, credit, calculation of balance) are part of the support domain; this is an indispensable function for which no one is prepared to pay. As a result of the subprime crisis, risk management is once again strategic; risk management therefore has become, for the moment, the core domain.

Management of Time Zones

In his work, Eric Evans discusses, as part of a project for an insurance company, the use of a management component for time zones (in order to correctly gauge the exact moment that a loss occurs, the U.S. having several time zones.) The developers handled this component quite thoroughly, being that it was the sort of well-defined task so dear to the heart of an engineer. The result was a bundle of functionality. This turned out to be a poor utilization of resources, as none of the conversions were attained; nothing but storage. And the main outcome was negative: neglecting the core domain, namely insurance. Management of time zones is a generic domain.

Why Make a Distinction Between Different Types of Domain?

During the conceptualization of a large-scale system, numerous components are implemented and put into operation. All of these components certainly have a role and participate in the success of the system in its totality. Nevertheless it is very easy to lose sight of the essential functions of the system. On the other hand, the harsh reality is that all parts of the system cannot benefit from a spotlight on quality because resources are finite! It is crucial to concentrate on the core domain; in practical terms this means mobilizing the best members of the team—by the way, why are the best people always assigned to the most technical part of the project?

Given a choice between two methods of refactoring, the one that most improves the core domain should be preferred. Because of these elements, rarely can the core domain be implemented using off-the-shelf software. In the end, it is best to avoid an external assessment of the core domain, as this knowledge builds itself over time.

What, may I ask, is your own core domain?

Unit Test In Real Life

Test Driven Development is an essential practice of the Agile approach. It allows an immediate feedback on the development activity and most of all it participates in the design activity by allowing it to emerge little by little according to the advancement of the system tests (great presentation on Emergent Design (PDF) by Neal Ford). I really like to try to transpose software concepts into the real world and unit tests are a part of this attempt, this article is an essay about what units tests looks like in real life.

A test is composed of the following elements:

  • A component to be tested situated in a very specific state (sometimes called the fixture)
  • The action performed on that component (sometimes called the System Under Test)
  • The assertion that can be done on that component after this action

These three components of a test can be summarized with the famous triptych Given/When/Then from BDD. Now let’s go back to the real world, the tests that we’re going to be able to carry out will sometimes concern real persons (“people”) with whom we interact. So, if I apply the BDD triptych in real life, the given fixture is the person, when that person does something, then I assert the result. Here are a few examples of unit tests IRL (In Real Life):

An anecdote is linked with the hard rock band Van Halen about their tour demands which have been deemed unrealistic and capricious (Thanks to @espritriche for telling me about that anecdote !:-)). In the contract they made their contractors sign during their tour included a particular clause which demanded that a bowl filled with M&Ms must be placed at their disposal in their lodge, BUT the bowl could not contain ANY brown M&Ms. David Lee Roth tell us the story in his biography:

I came backstage. I found some brown M&M’s, I went into full Shakespearean « What is this before me? » . . . you know, with the skull in one hand . . .and promptly trashed the dressing room. Dumped the buffet, kicked a hole in the door, twelve thousand dollars’ worth of fun. The staging sank through their floor. They didn’t bother to look at the weight requirements or anything, and this sank through their new flooring and did eighty thousand dollars’ worth of damage to the arena floor. The whole thing had to be replaced. It came out in the press that I discovered brown M&M’s and did eighty-five thousand dollars’ worth of damage to the backstage area.

The presence of even one brown M&M's in the bowl was enough to cancel the contract in its entirety with no compensation for the contractor. Actually this is the perfect example of an IRL Unit Test because this has nothing to do with rock-star diva-ism since the reason for this clause is to allow the group to check that the contractor has carefully read all of the clauses of the contract. If the M&M clause wasn’t respected, the group had every reason to assume that the other more important clauses hadn’t been as well ! In the case of the presence of brown M&Ms, the stage was effectively incapable of supporting the weight of the equipment for the tour. The contractor hadn’t taken into account the exact weight of the equipment specified in the contract just as he hadn’t taken into account the infamous brown M&M clause.

Another example which is appropriate for our geek activities comes from a post by Derek Sivers.

If you’re looking to hire a service provider on Odesk or Elance you can include in the specifications of the job a clause asking for a short and easy action like this one: “To separate you from the spammers, please write I AM A REAL GEEK as the first line of your bid. We will delete all bids that do not start with this phrase, since most bidders never read the requirements. Thank you for being one who does.” You’ll get many offers, but if they don’t have your magic phrase at the top (“I AM REAL” or whatever), delete them. This is very hard to do, since you’ll feel thrilled that so many people are offering to help, saying things like, “We have looked at your project and would be glad to complete it immediately,” but trust me and delete those. If they didn’t read something marked as VERY IMPORTANT already, you don’t want to work with them.

Another one is the post from Jeff Atwood last week about « How to hire a programmer? »

I know it sounds crazy, but some people who call themselves programmers can barely program. To this day, I still get regular pings from people who tell me they had candidates fail the most basic programming test imaginable. That’s why extremely simple programming tests are step one of any sane interview process. These tests should happen online, and the goal is not to prove that the candidate is some kind of coding genius, but that they know what the heck programming is. Yes, it’s sad and kind of depressing that this is even necessary, but if you don’t perform this sanity check, trust me – you’ll be sorry.

Some services that do online code screening (I am sure there are more, but these are the ones I know about) are Interview Zen and codility.

(UPDATE 04/06/12 : I’ve stumbled upon that very good one hiring filter from Chris Stucchio in Hacker News):

The sanity check he proposes first is a simple « Hello world » to be written by the applicants, it’s a kind of unit test as it involves very little action on your own to be performed and can then very easily filter the wheat from the chaff afterwards.

To summarize, in your offer you can include a task which is easy to do for the service provider and easy for you to check. If it isn’t done, you can be sure the rest of your demands might be treated the same way.

But what are the other kind of assertions we can perform? the easiest being the assertions linked to time (being on time for an appointment, etc.). Odesk even includes a tool which allows them to take a regular screenshot of the contractor’s screen and then allowing you to check the contractor’s activity. For cyclic assertions like in agile projects, unit tests can then be regularly executed so as to insure a constant feedback and to not deviate from a goal. The practice of Standup meetings is for me a part of a regular feedback loop at the core of the team allowing team members to get feedbacks from their peer’s actions as everyone tells the others: “what I’ve done, what I’m doing, what is blocking me, what I’ve learned, how I feel”. I can’t think of an assertion (other than a binary one) about a person’s location, maybe you’ve got examples to give in comments?

The assertions made above concern external people but now can we make our own assertions on ourselves? The “quantified self tools” are part of these tools which allow us to have a feedback about our own activities : on my part I use “Run Keeper” for jogging, “Rescue Time” for my professional activities and “Sleep cycle” for my sleep.

And what about you, which tests do you do in real life?

Feedback Loop: A Must-Have for Every Action We Perform

Feedback is an essential notion in usability. This is the notion which struck me the most as I read the book « Design of Everyday Things » by Donald Norman and of which I am now the most attentive to in my every-day life. This article explores the way we can apply the feedback concept in other field than usability.

But first *how can we define what Feedback is? *

Feedback is data or results which are given in return for a completed action. me


Every action should have a reaction Arnie Lund

Feedback is also a central concept in system theory, especially cybernetic system theory, every action performed by a system on another one needs a feedback to measure its effect and so adjust its action to the reaction it perceives. You can replace « system » in the previous sentence with « human ». Also the feedback can be asynchronous with a response delay that can vary in time.

Examples Of Feedbacks In The Physical World

Donald Norman, in his book, uses as an example telephone keys which produce a sound when they are correctly pressed (a different sound to every key too). This allows the user to know that his action has been taken into account.

On my part, I remember for example having rented a car of a recent model a while ago and during the ignition not hearing the engine (‘feedback’) and spending 30 seconds just looking for a feedback to my action of ignition, actually the dashboard lights were on but unfortunately they were flooded in sunlight. Until I finally put it into gear and the car started going in reverse – the engine was on and the car had been operational the entire time!

Another example is the knobs which control the volume on my old Dell had a horrible feedback: a bar would appear on the screen but gave no indication of what the real level of volume was. Now on my Mac, as well as the appearance of a visual bar, the volume buttons emit a beep of the volume which has been modified by my action – a feedback I personally find much more useful!

In short, every action must have a feedback worthy of the name, especially in software!

Agile Practices Are Built With Feedback Loops

I find that the Feedback notion is a fundamental one and can be applied to our organizations. It is also a good way to explain the Agile practices as they are part of a feedback loop with just a different time laps which depends on the action (I stick to the number 3 to emphasize the unit change for each practice, a kind of Rule of Three ! :-) ). Hence:

  • Pair programming: feedback within 3 seconds
  • Unit tests: Feedback within 3 minutes
  • Refactoring and continuous integration: feedback within 3 hours
  • Standup meeting and planning: feedback within one to 3 days
  • Iteration: feedback within 3 weeks

The Lean Startup movement and the Minimum Viable Product (MVP) notion also try to integrate a feedback loop with startup’s clients during the product or service building process.

This feedback can sometimes be quantitative and very rational like with practice of A/B testing which consists of providing two different version of the same website/application and collect metrics about the different behaviors from users according to each version.

The faster the return, the better, which is why real-time BI systems are popular. Because, like in real life, feedback makes it possible to adapt the action in a continuous manner according to the returns.

In short, every activity can be questioned according to the feedback it returns. And how about you, what are your feedback loops for your activities?

Simple and Easy Software Design – QCon London 2012

The talks I remember the most on QCon‘s second day are those from Rich Hickey. I was lucky enough to attend both the keynote in the morning (slides available) and the one about the modeling process (slides also available at the GotoCon website) in the evening at the London Java Community Group.

I was pretty amazed by the clarity of Rich’s thoughts in the Clojure documentation but I found a real visionary with the datomic service disclosure a few days ago. He’s a sort of philosopher, who tries to go very deep at first to grasp the essence of concepts like state, identity or time and then applies his thoughts to technology and I’m fond of this way of thinking and doing.

I already wrote about state, identity and behavior a few weeks ago. Here is a more general way to write about simplicity and is also the subject of Rich’s keynote at QCon : « Simple made easy ». Simplicity is a subject that fascinates me, as I see it as one of the ultimate goal in my design activities. In the following sections I will humbly mix my thoughts on that subject (sentences starting with « I ») with the ones from Rich (sentences starting with « Rich »).

Simple and Easy

Rich started by talking about the core and boundaries of these two words:

  • Simple : one fold, which is not composed
    • From the latin simplicem, "without a fold"
    • Is the opposite of complex
    • It is an objective concept that is independant of the human observe
  • Easy : lie near

Complication or complexity?

As a first step to grasp the concept of « simplicity » I started to look at what the opposite, complexity, is. So I separate at first complication and complexity:

  • Complication:
    • Deterministic, has a lots of details and connections, but with linear « cause and effects »
  • Complexity:

Finally, even though it’s interesting from an intellectual point of view to separate complication and complexity I think we can just use the following definition:

Complexity is a measurement of how difficult it is for someone to understand how a system will behave or to predict the consequences of changing it Therefore the latter definition is relative to the subject trying to understand a system, so I think that what is pertinent to analyze here is the subject’s perception of complexity.

What makes a system difficult to understand?

High level of variety in its components

Low variety in the system vs High variety in the system's constituents

Lack of order

Same relations between the elements but some organization (partitioning) added on the left

Same relationship between the elements but some organization (partitioning) was added to the left Same relations between the elements but organization (grouping) added

High degree of connectivity

Linux apache system calls for serving an image

Windows IIS system calls for serving an image

Which one do you prefer to work with? :-) But is simplicity only a lack of complication and complexity? It’s a good start (high order, low connectivity and low variety) but I think there is something more to it: *simplicity is also defined by what you add with clarity, purpose, and intentionality *(look at the DDD intention-revealing interface pattern). I think the most difficult part of simplicity lies in the latter.

Complexity and Simplicity toolkit

Rich’s morning talk was a praise to Clojure and a line of arguments about why Clojure is better on simplicity and easiness. Rich reborns an old english verb « complect » : « To join by weaving », and compare complexity and simplicity constructs to what they complect. Actually, it was a confrontation of the OOP/imperative way of thinking versus the functional one with the exposure of the different concepts on each side :

Complexity tool kit

Construct complects Elements
State complects everything that touch it
Objects complects State, Identity, Value, Operations
Methods complects Function and state, namespace
Syntax complects Meaning (derives meaning), order
Inheritance complects Types
Switch/matching complects Multiple who/what pairs
Variables complects Value and Time
Imperative loops, fold complects What and How
Actors complects What and Who
ORM complects OMG
Conditionals complects Why and the rest of the program

Simplicity toolkit

Construct Get it via
Values final, persistent collections
Functions a.k.a stateless methods
Namespaces language support
Data Maps, arrays, sets, XML, JSON etc.
Polymorphism a la carte Protocols, type classes
Managed refs Clojure/Haskell refs
Set functions Libraries
Queues Libraries
Declarative data manipulation SQL/LINQ/Datalog
Rules Libraries, Prolog
Consistency Transactions, values

It appears that the Clojure concepts have all the simplicity labels :-). Nevertheless it’s a good kick in the ass of the OOP approach.

What brings simplicity in our programs?

  • Composition of simple components together
    • This is really the fundamental way to have a simple design in a direct application of the Single Responsibility Principle.
    • In tune with the Unix philosophy that composes small programs (cat, grep, sed, awk) and link them together through text interface (the pipe). Actually, I think each point of the Unix philosophy helps bringing simplicity in every design.
  • Modularity by partitioning or grouping
    • But be careful, grouping and partitioning are enabled by simplicity, not by the opposite.
  • State always bring complexity

Example of incidental complexity with the « order » concept

Then Rich talks about the « order » concept, which gives a concrete example of one that brings incidental complexity and infects a lots of our usual programming constructs without any usefulness. Why « order » brings incidental complexity? because modifications are inhibited: a change in the order impacts the usage others have on the collections.Hence we find the « order » concept in the following constructs on the left while the construct on the right side fulfill the same needs but without that over-added « order » concept.

Order in the Wild

Complex Simple
Positional arguments Named arguments or map
Syntax Data
Product types Associative records
Imperative programs Declarative programs
Prolog Datalog
Call chains Queues
XML JSON, Clojure literals
... ...


Why take all this times to write about simplicity in what can be seen as very philosophical? because simplicity is a key concept and a key skill to design our softwares, not only in their technological aspects but very firstly in their domains. Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not dealt with in the design, it won’t matter that the infrastructural technology is well-conceived. A successful design must systematically deal with this central aspect of the software Eric Evans, author of Domain Driven Design. « Simplicity » and « Common Sense over Common practice » was also the corrolary of the « test considered harmful » and « ORM OMG ! » that were higlighted several times during the conference. What I like the most in QCon is the « think differently » that I could feel in some talks given by opinionated people. And after that exposure I started looking at things and thinking differently, so thank you Rich for having given me that! Other write-up about that second day at QCon :