The road to the right software architecture can be very long. Especially when you're not a professional software architect who helps his customers with developing complex applications day by day.
...
My latest "achievements" are - again - having a deep impact on the big picture of the Oregami application. This summer I finally got some time to get into the topic "Domain Driven Design" (DDD), which Wikipedia describes as an "approach to software development for complex needs by connecting the implementation to an evolving model." You might think "so what?". I read the book "Implementing Domain Driven Design", which enlightened me in more than one way. Many of its topics are an obvious perfect match for Oregami development. During the last months, even before I knew about DDD, I found some similar solutions for small aspects of the whole thing myself, which creates a rather good feeling.
But what is "Domain Driven Design" all about in the end? I will try to resume the major parts of DDD as I understand them:
- Domain experts work very closely together with developers to create a "ubiquitous language" and describe the domain model with that language.
- The complete business model is not modeled in one big, comprehensive model, but is instead divided into multiple, smaller sub domains ("bounded contexts") according to some special rules.
- You distinguish between "real" entities and value objects, the latter should be used as much as possible, because they are in many aspects more controllable than entities. This gives you some major technical advantages.
- Every Bounded Context (BC) consists of exactly one network of entities ("Aggregate") with one main entity which is called "Aggregate Root". If a transaction alters the state of the application, only one aggregate at a time is allowed to be changed. It's not allowed to change more than one aggregate in one transaction.
- A connection from one BC to another may only reference the aggregate root of that BC. The aggregate root is responsible for all rules of that model. It's not allowed to span rules over several BCs.
During my investigations I also discovered the concept of the so-called "Hexagonal Architecture". Alistair Cockburn writes about it with this essential sentence: "Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases." Wow, that's exactly how software should be: universally useable, easy to expand and easy to test. This architecture concept is sometimes called "Ports and Adapters" or "Onion Architecture", too, starting from the inner application code of the core domain, going through the application service layer to the outer infrastructure, there are no dependencies from the inner to the outer parts. Doing this makes your core code independent of the technical infrastructure, which again leads to better testability (infrastructure "ports" can be swapped easily, e.g. with in-memory variants) and great extensibility (One can add an additional "adapter" to support more clients which use your software, e.g. via ReST or queues).
...