Alexander Steshenko | On Software Engineering

DDD Demo application overview

It’s going to be a simple application. I’m not going to demonstrate how to solve the most profound problems you may face when trying to apply DDD. I want to show how fast it is to prepare a working prototype of a system with non typical business logic. There are matters of performance and some particular special cases which I may also want to talk about and do some investigations later on.

I’m going to introduce Session as a domain model term. It is mistakenly considered by many as an exclusively technical and language-specific aspect. For that I’m going to sacrifice the built-in PHP sessions mechanism and write my own as my domain model will require. Just keep in mind that for those mostly isolated from the rest of the model things like sessions you may use some automation such as a language or a framework’s feature - in your own projects.

CRM application

I’ve considered a few areas that would do well for a demonstrative application and I’ve decided to go with a basic CRM solution ( In short - I’m going to create a system that helps companies process their clients and tasks that occur. (It is a coincidence that I’m currently holding a developer position in a CRM company)

The system overview

Here is how I see the system to be helping out companies:

  1. People register their company in our system, choosing a subscription plan.
  2. They get an admin account after that and add some their staff as users
  3. A user adds new clients records to the system
  4. A user creates tasks and links them to a client
  5. A user works on tasks and leave comments
  6. When a task is done, the responsible person marks it as resolved

I’d say that business logic here is not complex and it will do for an example. This is also the kind of tasks where business logic tends to grow and change quickly.

Describing the task

As I noticed earlier, all a programmer has to do when implementing some business operation using DDD is to properly describe the requirements as they are using a programming language. Even though it’s still true, another challenge appears here: you should develop a skill of defining those requirements in a way so it’s easier to actually code them. You may want to google things like system use case, user stories etc - I think those are related.

It isn’t DDD specific either, but will be especially handy to have business statements that are easily translatable to code.


Comments and feedback are much appreciated. See contact details here