[x] replace in domain http clients update call with (event handler? injected service from host?) invoking of some service to pass data from domain object into host or injected service to send update to traffic api. research possible patterns here. Add to adr.
[x] Domain object Plane should not have http client directly and handle connection logic. Export http client logic to kernel, expose through interface, make a layer / service for outgoing communication in plane and airfield.
[x] Domain object Plane should not have stopping token, that logic belongs in host service or worker, plane should expose how to start update and stop it, business domain behavior. Plane as a domain object should only know that it needs to send data update. The fact that it goes as a http request, as well as config where to send it and what http client to use should not be handled by a domain object. It should be in either background worker or sth in between.
[x] plane lifecycle should be separate from plane domain object, which is to expose public manage methods, but be managed by some manager service
[x] Plane should be usable in simulated as well as actual hosting contexts.
[x] export AssignName from domain to ost service logic
[x] replace url info from plane domain object, move them to config/service
[ ] Plane should be a domain object entity. Behavior exposed through methods. Outer host - managing it. Confirm with DDD guidelines. (that pluralsight course on pet clinic scheduler).
[ ] navigation (shared kernel?) class have move plane method, that is leaking language, It should have move point x by speed y on time t. Navigation in plane or domain specific language (like accuracy when we consider destination as reached) should be in plane or somewhere in domain. So some navigation logic should go to domain and some to shared kernel.
[ ] DDD Documentation - design bounded context with subdomains, use proper domain object, entity and value object - provide charts
[ ] refactor SelectNewDestinationAirport in Plane - discovered after DDD review
[ ] refactor bad weather generation
[x] attach pdf with code review on current (2021.09) codebase snapshot
[ ] model refactor issiue #16 is also important from proper DDD point of view - hold this ticket active until #16 its completed
[ ] refactor into a separate service re try adding plane/airport during system init - "KeepTryingToAddAirportUntilSuccessful" - discovered during #50 and #42
[ ] Add at project level architecture a separate layer (onion?) folder called external communication - have http and mqtt connection logic happening there, use it in planeManager through services