# LH DDD

!include <kubernetes/k8s-sprites-unlabeled-25pct>
package "Delivery Infrastructure - Kubernetes Cluster" {
  component "<$crd>\nAPISpec" as apispeccrd
  component "<$crd>\nAPIProxyPolicy" as policycrd
  component "<$crd>\nAPIProxy" as apiproxycrd
  component "<$crd>\nAPICatalogEntry" as apicatalogentrycrd
  component "<$pod>\nApigeeOperator" as operator
}

package "Apigee" {
    component APISpec
    component APIProxy
    package "portal" {
        component APICatalog
    }
}

apiproxycrd --> policycrd
apicatalogentrycrd --> apispeccrd
operator --> apiproxycrd
operator --> apispeccrd
operator --> apicatalogentrycrd

operator --> APISpec
operator --> APIProxy
operator --> APICatalog

actor Developer as dev
dev --> apiproxycrd
dev --> apispeccrd
dev --> apicatalogentrycrd

actor LighthouseDeveloper as lhdi
lhdi --> policycrd

storage Platform {
  object Container
  object "Kubernetes" as k8s
  object "Operator" as ao
  object "GitHub Repo" as repo
  object webhook
  rectangle publishAPI #lightblue {
  
  }
  
  k8s .. ao
  k8s .. Container
  repo .. webhook 
}

storage Apigee {
  object Proxy
  object APISpec
  object APICatalog
  object APICatalogEntry
  object portal
  
  portal .. APICatalog
  APICatalog .. APICatalogEntry
}

queue "Messaging Mechanism" as mm {

}

rectangle "APIPublished" as publishedout {
}

rectangle "APIPublished" as publishedin {
}



storage Backstage {
  object Techdocs
  object "Gateway Manager" as ApigeePlugin
}

webhook --> publishAPI
publishAPI --> publishedout
publishedout --> mm
mm --> publishedin
publishedin --> ao

The developer publishes an API to the public gateway 
  Given an API that is ready for publishing
  And a catalog entry definition for the API
  And a spec definition ffor the API
  And a proxy policy definition for the API
  When the developer publishes the API to the public gateway
  Then a proxy is created 
  And a spec is created
  And a catalog entry is created

- Mixing a bunch of stuff together. Usually you wouldn't mix the domain / aggregate diagrams with the command / domain events
- There's also a bunch of stuff here that doesn't have the right abstraction level. This also assumes that we'll use an event based architecture (messaging mechanism).
- Ultimately the code is the only artifact of the domain model which is why you want to use something like BDD or Cucumber that ties requirements to tests
---
- We're may not be building this so it might be confusing to try to map it to what we're doing
- The important concept here is that the domain model is distinct and verifiable on its own. It contains business logic.
- Right now it's not clear to me what the implementation looks like- is the domain model a set of microservices + the output adapter?
- maybe a lot of the stuff I have listed as aggregates are actually application services so they exist outside of the domain model. "Kubernetes" is not really a semantic abstraction