Split anemic contract into multiple contexts models

[mjoniec]

Currently application uses everywhere single source of truth contract model as a nuget.

Example issiue: contains color data only needed in UI but is used everywhere.

• what does DDD guidelines say on this? Aggregate vs Entity on given requirements ...
• is it worth to create multiple models ?
• can color info be only applied on UI level model ?
• maybe create a model with color data that is only used between traffic api and UI ? Smaller contracts for info exchange between services.

[mjoniec]

is this ticket still valid? see into it.

[mjoniec]

After DDD code review: Valid big time - bumping priority

from DDD review: Contract project - some common contracts between bounded context is needed - partially ok - each bounded context / layer inside project should have only info that it needs for its work. Can be improved - eg.: color info not needed everywhere. Plane should have its Name private property, not a contract. Contract like structure with plane info should be created and returned by API in methods for UI. Similar method with airports but intended for Backend Plane should have list of airports with names and coordinates, not every property in airport. Same model everywhere simplifies code a lot and may be good for small project complexity, but the big code smell that it causes is that the projects and services seem to work a bit like a distributed state machine.