1. Why Domain Driven Architecture?
2. Principles
3. Tooling
4. Inspiration

Why Domain Driven Architecture?

Everyone has it's own architecture, so why the hack do we need just another architecture? But if you've a closer look, you will find your architecture incomplete. I do not know, whether that's always true. But I know, that's true for every company and every architecture, I've seen.

So

• we collaborate on an architectural blueprint, which is open for usage, contribution, questions & discussions.
• we use GitBook to publish our results: https://www.gitbook.com/book/dda/domaindrivenarchitecture
• our contributions are published under Creative Commons
  
  DomainDrivenArchitecutre by architecture community is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
  .

Principles

In IT total freedom is most of time a disadvantage. Software developers get lost in plenty of options. So

This restriction is based on experience and our "feeling for IT material". In order to anchor discussions of such soft topics, we try to find relevant principles and talk about their impact on real projects.

• Technical Principles: We've to understand our tools & material.
  • Domain oriented decomposition: Makes IT-Systems more understandable.
  • Separate Domain from infrastructure - infrastructure and domain have different speed of change.
• Social Principles: Architecture is more about teaching than about laying rows of bricks.
  • Enable over streamlining: Architecture has to prove evident afield. Don't stay in your ivory tower.
  • Ease over Enforcement: Provide an easy way to follow your ideas.
  • Teach architecture: Decisions have to be well founded, find a closed set of principles and offer discussion.

Tooling

We relay heavily on cloud, kubernetes, git, Markdown and OpenSource.

Inspiration

If you search for inspiration, you may want to have a look to following literature list: