title: DDD and heavy infrastructure based 'domains' - does DDD fail here?
body: <p>My company's rarely developing stuff like fancy web shops, financial systems, request/result APIs... instead, for many of the applications we don't even need to store data at our side, thus don't need repositories, entities. What we're mostly doing is creating management systems for network devices, facilities. This means:</p>
  
  <ul>
  <li>The whole 'domain' is infrastructure based, with hundreds of synchronous, stateful protocols</li>
  <li>Most of the functionality our systems provide are written inside plugins where configuration, data and methods are tightly coupled</li>
  <li>Even if it's bad practice, for our stuff we often need configuration over convention</li>
  </ul>
  
  <p>Now I'm wondering - is DDD applicable here? Does it make sense to separate the business logic from the infrastructure layer when the business layer is the infrastructure layer? Do you have any experiences with such scenarios? How is it possible to leverage certain e.g. infrastructure concerns into the domain?</p>
  
  <p><strong>Edit</strong></p>
  
  <p>I apologize if I was unclear with my statement "<em>when the business logic is the infrastructure layer</em>". I am well aware of the purpose and boundaries of both layers in DDD, but see this example:</p>
  
  <p>A client wants you to write a SNMP device management software. He doesn't really care about SNMP itself since he may not even understand the protocol, but he does care about the "device management" part, which can be considered as the 'domain'. Now, SNMP is a binary-data, TCP/IP based protocol and somewhat complex. If you are going to write a client implementation by yourself, you probably won't be done within the next few weeks. So, what do you do? You use a framework, a library which contains all the fancy magic to get you started quickly.</p>
  
  <p>Now, SNMP is a very 'dynamic' protocol. You don't know what you really get when you ask a device for its configuration. But you would like to store this configuration into a database (using your repositories) because the client asked you to do so. So you create like a dozen value objects, classes etc. to represent what a device can have. But what about the SNMP library? Well, it ships with it's own classes for every possible type a SNMP device can offer. And since the domain should never be coupled to the infrastructure layer, you are left with spending your day creating mappers from your domain entities to the SNMP classes.</p>
  
  <p>Well, fine. Once you're done, the client has another request: He want's to get a Email if a device isn't reachable anymore. So you create your email-sender-service, write some business logic that fetches the email of the client from a configuration file.. when what happens? Of course, when the device isn't reachable - something you only detect on the infrastructure layer. Hence, you need to find a way to notify the domain layer about an event on the infrastructure layer, e.g. using a event bus. So again, you need to introduce a concept from the infrastructure layer in your domain layer: A "DeviceNotReachableEvent", something that is already there in the SNMP library..</p>
  
  <p>You see where this is going? For every concern of the infrastructure layer, you have to create a pendant in the domain layer because your domain is something that bases on 'outer' infrastructure. Of course what happens on the network is a domain requirement, but there wouldn't be any need of doing the same stuff nearly twice without DDD.</p>