/usr/portage

Dokumentation über Adorno und die Kritische Theorie 0

Theodor W. Adorno – Dokumentation 1. Teil

Theodor W. Adorno – Dokumentation 2. Teil – “Wer denkt, ist nicht wütend”

Filed under Dokumentation, Kritische Theorie, Theodor W. Adorno & no comments & no trackbacks

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

Leaflet: PHP development in 2009 6

• Develop object-oriented code
  • Avoid static cling
  • Avoid global state
  • Use dependency injection
  • Use a framework if appropriate
  • Refactor continuously
• Use a VCS, preferably a decentralized
  • Have commit notifications configured
• Utilize continuous deployment
  • Deploy with tools like capistrano
  • Deploy phar files
• Test your code
  • Use continuous integration to run tests, create and deploy artefacts
  • Unit test your code with PHPUnit or SimpleTest
  • Have database migration in place to ease schema changes, e.g. with dbdeploy
  • Use build tools like phing or ant
  • Have metrics configured and use them as a QA measure
  • Have a code sniffer in place
  • Acceptance tests with tools like Selenium
• Use rapid development tools like Zend Tool or cake
  • A fresh checkout should be up and running in a few minutes
• Monitor your (production) systems
  • Load monitoring with tools like Cacti
  • Event reporting and monitoring with tools like Nagios (for the enterprise, there is nothing else)
• Use a bytecode cache
• Love your code

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

Filed under Development, PHP, QA & six comments & no trackbacks