Implementing domain driven design
-
Alright, I thought I'd take up a new hobby project, and use it to try and implement some ideas on domain-driven design. In essense, the project is to develop a "Rigging Designer", that allows civil engineers to define rigging needed to lift heavy objects. I'm struggling a bit with how to implement the ideas of DDD, hence this question. The hierarchy of domain objects is: * Lift - a lift operation * LiftObject - the thing to lift * Weight - weight of the object, double * Cog - centre of gravity, position in X, Y, Z * Liftpoint - point where you can attach rigging, can have up to four * Id: Id, local to Lift * Position: position in X, Y, Z * Hook - a hook, can have up to two * Position - X, Y, Z position of the hook * Type: 1, 2, 3, 4 leg hook * Leg - a leg between a hook, and a piece of rigging, can have up to 4 legs per hook * Id - Id local to hook * LiftPointId The library / app will have two major components: designing consistent lifts (i.e. you can't connect two hooks to the same lift points), and solving them (i.e. calculating the load on legs and hooks). Alright, that's it for domain knowledge. Now my question: what do I treat as aggregates, entities and value objects? The way I see it now: 1. Lift is aggregate, since you can't modify any of the sub objects without needed to see if it is still consistent with the other ones (i.e. changing the cog changes the validity of the lift points). It's also an entity, since we want to be able to model multiple lifts. 2. LiftObject is an entity, although I expect that it can never be referenced by more than one lift (since modifying this entity would have implications to all connected lifts) 3. Weight and Cog are clear value objects 5. Hook is a (local) entity 6. Leg is a (local) entity First question: am I implementing the ideas of DDD correctly. Now, for my second question. I'll work on this project with a colleague, who will be implementing the solver. I intend to implement the following modules: * Common - contains interfaces describing the models * Designer - contains concrete implementations of the models in Common, used for creating and changing the models * Solver - uses the interfaces in common to calculate the loads on the hooks and legs Second question: I like the idea of defining interfaces (which are very short and readible) in the Common namespace, which allows me and him to
-
Alright, I thought I'd take up a new hobby project, and use it to try and implement some ideas on domain-driven design. In essense, the project is to develop a "Rigging Designer", that allows civil engineers to define rigging needed to lift heavy objects. I'm struggling a bit with how to implement the ideas of DDD, hence this question. The hierarchy of domain objects is: * Lift - a lift operation * LiftObject - the thing to lift * Weight - weight of the object, double * Cog - centre of gravity, position in X, Y, Z * Liftpoint - point where you can attach rigging, can have up to four * Id: Id, local to Lift * Position: position in X, Y, Z * Hook - a hook, can have up to two * Position - X, Y, Z position of the hook * Type: 1, 2, 3, 4 leg hook * Leg - a leg between a hook, and a piece of rigging, can have up to 4 legs per hook * Id - Id local to hook * LiftPointId The library / app will have two major components: designing consistent lifts (i.e. you can't connect two hooks to the same lift points), and solving them (i.e. calculating the load on legs and hooks). Alright, that's it for domain knowledge. Now my question: what do I treat as aggregates, entities and value objects? The way I see it now: 1. Lift is aggregate, since you can't modify any of the sub objects without needed to see if it is still consistent with the other ones (i.e. changing the cog changes the validity of the lift points). It's also an entity, since we want to be able to model multiple lifts. 2. LiftObject is an entity, although I expect that it can never be referenced by more than one lift (since modifying this entity would have implications to all connected lifts) 3. Weight and Cog are clear value objects 5. Hook is a (local) entity 6. Leg is a (local) entity First question: am I implementing the ideas of DDD correctly. Now, for my second question. I'll work on this project with a colleague, who will be implementing the solver. I intend to implement the following modules: * Common - contains interfaces describing the models * Designer - contains concrete implementations of the models in Common, used for creating and changing the models * Solver - uses the interfaces in common to calculate the loads on the hooks and legs Second question: I like the idea of defining interfaces (which are very short and readible) in the Common namespace, which allows me and him to
There's a physical model and a logical model; I don't see you addressing the logic model. ("value objects"?) You're creating interfaces, and unit tests, while the overall design is still incomplete, IMO. Wouldn't be able to "approve" your plan, Just what I "see".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I