/usr/portage

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

Entity

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.

Aggregate

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.

Repository

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 under DDD, Design patterns, Development & no comments & no trackbacks

Preventing cross site scripting by design 4

This is more or less a reply to Dynamic global functions in PHP. My main problems with delegating escaping in the template is the fact, that the people who normally work with templates, are frontend developers and designers. Those who do not and should not care about web security. That is a programmers/architects field. Nobody of the frontend developers should have the possibility to create security level artefacts by accident. So, when a value arrives the template, everything should be done. No special escape-calls should be necessary. I will show you how we do escaping and template value sanitizing at Neu.de. But let’s step through all common models in order to explain, why they are bad. I assume you know the basic MVC-terms, I will use here mostlye view and controller action. First of all, the most common approach. Just assigning variables as-is to the view component:

The second – much better approach – is to escape values before accessing them in the template. This is fine as long as you do not use objects in your templates.

If you have complex, nested objects encapsulating complex business rules, you do not want to convert them to an array to make it possible to escape them afterwards because of speed concerns. So if you pass an object with a method which returns fragile user input, your escaping logic is bypassed. See:

The solution is to wrap assign objects in mock objects. You can easily implement a mock object builder using PHP5s reflection features and create a simple proxy which escapes the return values of every call – or – if an object is returned – wrappes this return object in another mock object. And so on and so on:

Once you implemented that, a) your developers must not care about XSS anymore, they just use the framework and b) you can sleep better at night, because it is not likely probable, that your site is vulnarable against XSS. Sometimes you want to allow HTML-code passing to the template. That’s ok, just give the developer a chance to avoid mocking or escaping. If you want to audit your code for XSS security problems, just grep for the method signature.

Filed under Design, Design patterns, Patterns, PHP, Security, Websecurity & four comments & no trackbacks

The worker design pattern 1

I want to provide you a pattern I which I thought about a lot in the last days. Comments are appreciated.

Problem

1. You have a small object which is data and large set of operations which could be performed to that object


2. You want to keep the object’s method list small


3. The operations can be done in different ways, including different implementations


4. Your small object only knows how to read and save itself from the data abstraction layer


5. You want to batch process a number of small objects

Solution

1. You have a worker interface which defines the accessor API for the worker and how to add subjects
2. You can have multiple workers per subject
3. Your worker does the transformation, your subject is transformed
4. Your subject is kept light weight

Example

$image1 = new ImageBinary(array(‘id’ => 1));

$image2 = new ImageBinary(array(‘id’ => 2));

$image3 = new ImageBinary(array(‘id’ => 3));


	
$worker = new ImageWorker;

$worker->add($image1);

$worker->add($image2);

$worker->add($image3);

$worker->rotate(90);

Related patterns

Filed under Design patterns, Patterns, Software design & one comment & no trackbacks

eZ components - doing things fast and smart 0

If you use PHP for some years, you will often fight the same problems, which leads to a lot of unuseful work when implementing basic issues like a properly designed class to send mails in a sane way, parsing an INI-file, basic generating of PHP-code, logging to a file or database or an implementation for a persistant object. This components are often needed and you have to write them by yourself, if you want to work around the tranditional and outdated PEAR-packages. So, maybe some day, you have all the patterns you need and can begin to write code but how long does it take? Two years? For years? Not that sensible. So it raises productivity if you can use a set of components which are small, independent and designed for the current state of the language, means: PHP 5.1.x. eZ components by eZ systems fit this specification. You can solve the problems above and much more – analysing and modifying images, debugging, working with user input and, as surplus, you can work with PHP for shell-scripts with ConsoleTools.
As theory is supposed to be useless without practice, a small example for reading an INI-file. Let’s assume the following INI-file:

[context]
foobar = Bla
bla = blubb
whatever = bar

$reader = new ezcConfigurationIniReader();
$reader->init('/path/to/your/config/dir, 'config' );
$config = $reader->load();
echo $config->getSetting( "context", "foobar" );

Filed under Code, Components, Design patterns, ezComponents, Patterns, PHP, Technology, www & no comments & no trackbacks