An introduction to Domain Driven Design 0

My collegues asked me to write down some documentation on the basic concepts of domain driven design. Why not make a blog post out of it?

Domain Driven Design is all about the domain. The premise is, that what we call model, is the model of the real world process we are going to implement (the “domain”). DDD focuses on the domain of the problem, not on data, not on functions, not on control structures (although all of this stuff is used to implement them). Object technology fits pretty well into DDD as it allows us to narrow reality, as we can express behavior and state together (in an object).

A short glossary

Domain Layer

The layer in the application where the domain is expressed in terms of objects.

Domain Objects

All the objects in the domain layer


Entities are those domain objects that are equal by identity as they express a specific state of a specific entity in the system. Examples are a customer or a purchase.

Value Object

The opposite of entities in the domain layer. Objects that are equal because of equal values not because they are identical. A money object is a typical value object and so is an address.


An aggregate is an objects graph in the domain layer consisting of entity and value objects. A customer has a number of addresses and an order has a money value object.

Aggregate root

The top level object in an aggregate. In the customer example, the customer is the aggregate root and all the other objects are aggregations to the customer.


The repository acts like a Facade to the ORM components of a system. In DDD we focus only on the domain, we don’t care about ORM, we are ignorant against ORM. The repository allows us to be ignorant as it provides a simple, collection like interface to the user. Think of the repository as a factory to the persisted objects with a collection interface and being a facade to keep away all that sad details of ORM.

Ubiquitous Language

At the beginning everything is messy: you think that girl is stupid, she thinks you are a quirky nerd with strange hobbies and even more strange friends. A few dates later you both find an ubiquitous language which allows you to communicate efficiently. DDD encourages to find a set of terms to describe the system, that is modeled after the language of the domain. So the knowledge gathered in the development team about the domain is directly build into the systems core.

Filed on 13-05-2009, 00:12 under , , & no comments & no trackbacks

Leaflet: PHP development in 2009 6

What do you think is the state of the art in 2009?

Filed on 02-05-2009, 19:07 under , , & six comments & no trackbacks

New languages to broaden my horizon 6

I’ve read a bit and played around with Scala and Arc recently. I always recommend to learn other languages. Nobody is forced to get productive tomorrow in a language one learns but it always makes you a better programmer. This sounds trivial but I often met programmers who did only Java or only PHP or … you name it. There is nothing wrong with focusing on a language and getting really good at it, but ignorance is wrong. A good programmer always wants to learn, he basically defines himself through his fast ability to adopt new stuff. Everytime I look at different languages outside of my daily scope (which is mostly PHP and C, Ruby and Python for fun), especially on those who look exotic from the first view, I get something better. When I’ve tried to learn Erlang – even I totally failed at really getting it – I looked completely different afterwards at PHP constructs like array_filter(), array_walk() and the general concept of callbacks. When you halfway know both worlds, the functional as well as the object oriented, you just get more effective in applying the adequate methodology to solve an issue.

Back to Scala. Scala comes with a really feature rich object model. It provides classes, a concept well known to those who do Java or C++. Classes and methods may even be abstract. So far nothing new. But Scala provides a language feature so called traits. It addresses the issue that single inheritance is often too limited when it comes to stable (and convenient) compositions while mixins as in Ruby or classical multiple inheritance as in Python induce fragile, hardly maintanable hierarchies. The answer are traits. Traits allow stable compositions. A trait is basically a container for functionality. A class may extend from multiple traits, rename or overrride methods. Think on a debugging functionality – in this case implemented as a debugging trait – which should be used in a number of classes while each class has its own hierarchy. The debugger is than easily composited with the debugging consumer class while the class hierarchy is kept and the composition is stable itself. In PHP we do big wrenches to do composition. We introduce broker components to handle composited objects and what not. Traits are an elegant solution to the problem, a really impressive language construct.
Scala also provides generics. Generics are datatypes that can take other types while keeping type safety. Think you have an array and can enforce it to only accept instances of the class “Foo”. C#, Java and C++ implement that concept for a long time but nevertheless it is really handy.
I’m not really sure, how handy that would be in practice, but Scala enforces to explicitly overrride methods. I have the feeling that after a while one would do “override def method()” with the same implicitness as we do it today. Maybe this feature will be good for teaching object oriented programming.
The general syntax is a best of both worlds, the Java and the Ruby world. It is also possible to reuse existing Java libraries in Ruby, which makes it pretty attractive and lowers the entry barrier as a full stack of libraries are already present.

Arc is the newest baby by Paul Graham, the inventor of the bayesian spamfilter which mildens the pain for everyone of us dealing with email. Graham loves Lisp and it relatives. This is why Arc is very lisp’ish including polish notation for mathematical expressions. Actually the code examples are so incredible short to do a lot of stuff I guess I will try some sort of prototyping with it in the future. The plan is to design Arc to be useful in 100 years. This means time for adoption.

Filed on 08-02-2008, 02:02 under , , , , , , , & six comments & no trackbacks

Software representing structure 3

The current discussion about whether or not to use Smarty nowadays misses the point as it may simply depend on the environment. In a small development team, up to five people or so, you could just use the template-alike PHP syntax as all parts of the application are written by the same people with more or less equally shared responsibilities. This is what I would call a “single hands” process. Everything is done by everyone (that’s a bit oversimplified as in such environments intuitive structures emerging but let’s take it for now). This kind oft environment can often be found in startups and the like. This is were the process is really hands-on, the development process is often relatively agile as everyone is the others neighbour and there is often no explicit design stage. This is were you just ask your mate “hey, what’s the name of this template variable”. Such an environment has a lot of advantages but for sure a lot of disadvantages, often in terms of quality.

In other environments where responsibilities are much finer grained and balanced, a template engine might become a structural element of the development process as it represents a responsibility split between collegues. A template language is in fact an API for the user interaction/frontend developer. An API is a small subset of the factual possibilities, and this is where a template language might represents organisation prinicples. We as software developers define our API to encapsulate richer functionality and provide access to a well-thought (yeah, hopefully) subset of modification paths we want to allow on purpose. Just because the other guy does not need to know about the ugly internals. A good template language is a small subset of the language environment and exposes only functions which are really needed for view generation.

Beneath that, a template engine can structure the adoption of a pattern. Think about the MVC pattern, which is nowadays halfway common in web development environments. A template language in an MVC-alike environment enforces the usage of the view as “just a view”. While you would need to establish rules and procedures which subset of PHP is allowed correct for templating, a template engine establishs this rules and procedures implicitly. The other side of “do not try to solve social problems technically” is “do not try to solve technical problems socially”.

Filed on 14-01-2008, 13:01 under , , , , , & three comments & no trackbacks

New Years Targets 0

Of course, there are a lot of personal targets everyone will have for the next year. Stop smoking is typical, not mine, even I’m smoking. But for those working in the IT industry especially as a developer, David Coallier has a few useful hints how to improve your work by improving yourself. It is really a must-read.

Filed on 01-01-2008, 16:04 under , , & no comments & no trackbacks

Naive type casting for Zend_Config 1

We have added a feature I call naive type detection/casting to Zend Framework’s Zend_Config. Per default Zend_Config is not aware of types, everything is a string (except the crappy auto-detection parse_ini_file() does, but that’s another – ugly – chapter). Our patch provides an opt-in feature to detect wheither something is an integer, a string, a float or a boolean. It does that when a value is fetched, which should be the fastest way (most of configuration values are fetched one time, during a page load). The related ticket is #2312 and the latest patch is available here.

Filed on 17-12-2007, 08:08 under , , & one comment & no trackbacks

PHP trick: array or struct? 2

PHP does not have different primitive types for arrays and structs. It is all an array. The only difference is, that a list contains just ascending integers as keys, starting from zero, the rest is a struct.

if (array_keys($array) === range(0, count($array) - 1)) {
    // Is an array
} else {
   // Is a struct

In the Zend Framework this differentiation is needed in the XmlRpc-component. I’ve submitted a patch to make it more efficient.

Filed on 21-10-2007, 23:11 under , & two comments & no trackbacks

On examples 1

One thing I’ve learned is, that one of the hardest things to create are examples. Most people do not use examples as what they are, they use it as templates. So examples have side-effects. You write an example to demonstrate how a certain component works or should be used, but you did not follow the coding style of your organization unit. Developers then going to copy your stuff and bang, your errors are repeated again and again. Or, just do it like Yahoo: add a small piece of PHP for demonstration purposes and introduce a huge security problem. Here it is. Lucky for them, they seem not to use the same code in their live example.

Filed on 27-09-2007, 10:10 under , , , , & one comment & no trackbacks

Neu.de gelauncht 8

In den letzten Stunden eher nicht geschlafen, sondern Neu.de mit an den Start gebracht.

Filed on 30-01-2007, 06:06 under , , , , & eight comments & no trackbacks

Codarcheologie 0


Filed on 21-02-2006, 19:07 under , , , & no comments & no trackbacks

Proprietäre Software die begeistert 4

Heute, Zend Studio. Alles was ein PHP-Entwickler braucht.

Filed on 27-01-2006, 15:03 under , , , , & four comments & no trackbacks