Stabilize DDD namespaces and centralize common objects

[Whathecode]

According to DDD the semantics of namespaces should be:

• application: classes which are exposed to consuming clients
• domain: internal domain logic, not exposed to clients
• infrastructure: implementations specific to one particular infrastructure (e.g., database or serialization technology)

The current codebase did not follow this strictly. There are many classes which live in the domain namespace yet are exposed to clients. We want to have a strict separation so that people who want to develop clients on other tech stacks know which classes need to be implemented by them (the application namespace). Or, in case we do some type of code generation we know for which classes code needs to be generated.

In addition, many of these classes (erroneously residing in the domain namespace) are reused across multiple subsystems. This is for historic reasons mostly, since the implementation of CARP started with the protocols subsystem. However, we have since discovered most of these classes (such as DeviceDescriptor) are in fact more of a shared kernel (a DDD concept) and are therefore best moved to the common module in a application namespace. The goal should be that only the common module has base types which are extensible and passed across the architecture (protocols now).

While making such big namespace changes we should probably also look at:

• Proper DDD namespaces for:
  • protocols
  • deployment
  • studies
• Move InputElement to the element namespace. It seems inconsistent Data and the concrete types live in the same namespace, but this is not the case for input elements.
• Move application service types (such as ApplicationService and EventBus) to a services namespace. It seems disorganized that these live side-by-side with common types such as DateTime right now.
• Move StudyProtocol.Id to carp.common.
• Clean up/remove subfolders in carp.protocols.domain. (Moved devices, triggers, and tasks namespace to one carp.protocols.domain.configuration namespace since they only contained configuration classes for StudyProtocol.)
• Clean up/organize 'carp.common.infrastructure.serialization' (both main and test). Remove the subsystem-specific SerializersModule as all these types should be moved to common.
• Investigate whether dependencies on protocols can be removed (because so much is moved to common). (Nope, StudyProtocol and StudyProtocolSnapshot remains in protocols and best belongs there for now.)
• Update readme architecture structure. carp-protocols.md contains mostly carp.common stuff.
• Use singular/plural form consistently in module and package names

The suggested outline for new namespaces. Changes (and intended changes) in this PR are shown in bold.

• dk.cachet.carp
  • clients (or maybe, while we are at it, we should rename this to something more concrete/intuitive? e.g., 'runtimes')
    • domain
      • data
  • common
    • application
      • data
        • input (plural form?)
          • elements
      • devices
      • sampling (plural form?)
      • services (holds base classes and helpers for application services)
      • tasks
      • triggers
      • users
    • domain
      • users
  • deployments
    • application
      • users
    • domain
      • users
  • protocols
    • domain (I don't think plural forms for the two namespaces below make sense here)
      • configuration (this now groups the previous tasks, triggers, and devices since most of its contents were moved to common)
      • deployment
  • studies
    • application
      • users
    • domain
      • users

[ltj]

Much cleaner. Good job