Domain Driven Architecture

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 the question is, why not collaborate on architecture?
Doing it OpenSource?

So

Principles

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

a good architecture is characterized by the fact that it restricts the freedom - and nobody is complaining about his limitations.

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:

  • Cover DomainDrivenDesign Domain-Driven Design
    from Eric Evans
    Publisher: Addison-Wesley; ISBN: 0-321-12521-5
  • Cover Domain-Driven Design Quickly Domain-Driven Design Quickly
    from Abel Avram and Floyd Marinescu
    Can be downloaded@infoq
  • Cover Code Smells Code Smells
    CodeSmells will help for reviewing software. Original-Entry from c2 wiki
  • Cover Refactoring Refactoring: Improving the Design of Existing Code
    from Martin Fowler, Kent Beck, et al
    Publisher: Addison-Wesley; ISBN: 0201485672
  • Cover Aspect-Oriented Software Development Aspect-Oriented Software Development with Use Cases
    from Ivar Jacobson, Pan-Wei Ng
    Publisher: Addison-Wesley Longman, Amsterdam (20. Januar 2005); ISBN: 0-3212-6888-1
  • Cover Requirements Engineering Requirements Engineering und Management
    from Chris Rupp & SOPHISTs
    Publisher: Carl Hanser Verlag GmbH & CO. KG; ISBN: 3-4464-1841-5