Review DDD solution for a car manufacturing station
-
I have recently started exploring DDD and planning to use it. I am looking for some clarifications for which I have created a sample problem and designed a solution using DDD followed by some questions. Please go through it and revert should you need further details. Problem Statement: Architecture a manufacturing station for Vehicles which allows assembling of different parts and creating a vehicle. Architecture Style: Domain Driven Design (DDD) Domain terms and relationships - Manufacturing Station may have 0…* vehicles - Vehicle may be a Car/Truck etc. - Vehicle may have Engine, Transmission, Wheels, Music Player, Rear View Camera, etc - Engine could be of Petrol/Diesel - Transmission could be Auto or Manual - Wheel may have Tube or Tubeless Tyre - There may be millions of parameters within a vehicle such as Speed, RPM, Tyre Pressure. - A group of parameter belong to a certain component (Engine, Transmission, Wheels, etc). Hierarchical representation of System - Manufacturing Station o Vehicles Car/Truck • Engine (E) o Petrol/Diesel • Transmission (T) o Auto/Manual • Wheels (W) o Tube/Tubeless • Parameters (Could range upto millions) o Speed - E o RPM - E o Coolant - E o Tyre Pressure - W o Audio Level o RearCameraOn o DoorLocked DDD Solution ------------- Bounded Contexts (Identified) Station Vehicle Engine Transmission Wheels Bounded Context Details Bounded Context – Station Aggregate Root o Station Slots : List Entities o Slot o Vehicle : Car/Truck Value Objects Repositories o StationRepository Services o SlotService Events o VehicleAllocatedToSlot o VehicleDeallocatedFromSlot Bounded Context – Vehicle Aggregate Root o Vehicle : Car/Truck - How to manage inheritance and new vehicle types such as Bus Parameters: List Entities o Registration o Chassis Value Objects o Manufacturer o Model o Parameter Name Value Type Default Value Unit o Audio System Repositories o VehicleRepository Services o AssemblingService Events o
-
I have recently started exploring DDD and planning to use it. I am looking for some clarifications for which I have created a sample problem and designed a solution using DDD followed by some questions. Please go through it and revert should you need further details. Problem Statement: Architecture a manufacturing station for Vehicles which allows assembling of different parts and creating a vehicle. Architecture Style: Domain Driven Design (DDD) Domain terms and relationships - Manufacturing Station may have 0…* vehicles - Vehicle may be a Car/Truck etc. - Vehicle may have Engine, Transmission, Wheels, Music Player, Rear View Camera, etc - Engine could be of Petrol/Diesel - Transmission could be Auto or Manual - Wheel may have Tube or Tubeless Tyre - There may be millions of parameters within a vehicle such as Speed, RPM, Tyre Pressure. - A group of parameter belong to a certain component (Engine, Transmission, Wheels, etc). Hierarchical representation of System - Manufacturing Station o Vehicles Car/Truck • Engine (E) o Petrol/Diesel • Transmission (T) o Auto/Manual • Wheels (W) o Tube/Tubeless • Parameters (Could range upto millions) o Speed - E o RPM - E o Coolant - E o Tyre Pressure - W o Audio Level o RearCameraOn o DoorLocked DDD Solution ------------- Bounded Contexts (Identified) Station Vehicle Engine Transmission Wheels Bounded Context Details Bounded Context – Station Aggregate Root o Station Slots : List Entities o Slot o Vehicle : Car/Truck Value Objects Repositories o StationRepository Services o SlotService Events o VehicleAllocatedToSlot o VehicleDeallocatedFromSlot Bounded Context – Vehicle Aggregate Root o Vehicle : Car/Truck - How to manage inheritance and new vehicle types such as Bus Parameters: List Entities o Registration o Chassis Value Objects o Manufacturer o Model o Parameter Name Value Type Default Value Unit o Audio System Repositories o VehicleRepository Services o AssemblingService Events o
Praveen Raghuvanshi wrote:
I have recently started exploring DDD ...Architecture Style: Domain Driven Design (DDD)
Had to look that up and I can say is...versus what other idiom exactly? If you are not designing for the domain, then you are not solving the domain problem. Seems like there is no alternative there. So any process that reaches a solution of the domain would be DDD. Anything that doesn't would be, by definition, a failure.
Praveen Raghuvanshi wrote:
Domain terms and relationships
Hard to read (you could format it) and seems likely (guessing on a quick look) that you have an entity model. If so then you should start with the entities themselves first, before adding details (attributes.) Then add major attributes to clarify functional needs. And likely skip non-significant attributes at all for the model (they are implementation details.)
Praveen Raghuvanshi wrote:
o FilterAdded o FilterRemoved o FilterReplaced
Domain modeling should start with the actual/real domain. Above doesn't represent a real domain. When you build a car from scratch you don't remove nor replace the filter. If you service a car you might replace it, but that is not part of building the car from scratch. Modeling the entire real world eco-system of manufacturing to servicing is too large for a single model and would not be approached that way.
-
I have recently started exploring DDD and planning to use it. I am looking for some clarifications for which I have created a sample problem and designed a solution using DDD followed by some questions. Please go through it and revert should you need further details. Problem Statement: Architecture a manufacturing station for Vehicles which allows assembling of different parts and creating a vehicle. Architecture Style: Domain Driven Design (DDD) Domain terms and relationships - Manufacturing Station may have 0…* vehicles - Vehicle may be a Car/Truck etc. - Vehicle may have Engine, Transmission, Wheels, Music Player, Rear View Camera, etc - Engine could be of Petrol/Diesel - Transmission could be Auto or Manual - Wheel may have Tube or Tubeless Tyre - There may be millions of parameters within a vehicle such as Speed, RPM, Tyre Pressure. - A group of parameter belong to a certain component (Engine, Transmission, Wheels, etc). Hierarchical representation of System - Manufacturing Station o Vehicles Car/Truck • Engine (E) o Petrol/Diesel • Transmission (T) o Auto/Manual • Wheels (W) o Tube/Tubeless • Parameters (Could range upto millions) o Speed - E o RPM - E o Coolant - E o Tyre Pressure - W o Audio Level o RearCameraOn o DoorLocked DDD Solution ------------- Bounded Contexts (Identified) Station Vehicle Engine Transmission Wheels Bounded Context Details Bounded Context – Station Aggregate Root o Station Slots : List Entities o Slot o Vehicle : Car/Truck Value Objects Repositories o StationRepository Services o SlotService Events o VehicleAllocatedToSlot o VehicleDeallocatedFromSlot Bounded Context – Vehicle Aggregate Root o Vehicle : Car/Truck - How to manage inheritance and new vehicle types such as Bus Parameters: List Entities o Registration o Chassis Value Objects o Manufacturer o Model o Parameter Name Value Type Default Value Unit o Audio System Repositories o VehicleRepository Services o AssemblingService Events o
You're modelling a "Bill of Materials" for a vehicle's "dealer invoice". Not exactly a "vehicle manufacturing station". For that, you need more "functionality".
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
You're modelling a "Bill of Materials" for a vehicle's "dealer invoice". Not exactly a "vehicle manufacturing station". For that, you need more "functionality".
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
Can you share some thoughts on modelling this problem?
-
Can you share some thoughts on modelling this problem?
You have not stated (or determined) what "problem" you are trying to model / solve. Stating that one wants to build a "car manufacturing station" is not a proper "problem definition" and will lead to nada.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal