Click here to Skip to main content
15,908,906 members
Home / Discussions / Design and Architecture
   

Design and Architecture

 
GeneralRe: user data system for a web-based e-mail service Pin
Richard MacCutchan18-Jan-24 22:01
mveRichard MacCutchan18-Jan-24 22:01 
GeneralRe: user data system for a web-based e-mail service Pin
jschell19-Jan-24 5:01
jschell19-Jan-24 5:01 
GeneralRe: user data system for a web-based e-mail service Pin
RedDk19-Jan-24 8:15
RedDk19-Jan-24 8:15 
GeneralRe: user data system for a web-based e-mail service Pin
jschell18-Jan-24 4:18
jschell18-Jan-24 4:18 
GeneralRe: user data system for a web-based e-mail service Pin
Richard MacCutchan18-Jan-24 4:50
mveRichard MacCutchan18-Jan-24 4:50 
GeneralRe: user data system for a web-based e-mail service Pin
jschell19-Jan-24 4:57
jschell19-Jan-24 4:57 
AnswerRe: user data system for a web-based e-mail service Pin
k505416-Jan-24 6:34
mvek505416-Jan-24 6:34 
AnswerRe: user data system for a web-based e-mail service Pin
Gerry Schmitz18-Jan-24 7:04
mveGerry Schmitz18-Jan-24 7:04 
GeneralRe: user data system for a web-based e-mail service Pin
Eddy Vluggen18-Jan-24 7:30
professionalEddy Vluggen18-Jan-24 7:30 
GeneralRe: user data system for a web-based e-mail service Pin
Gerry Schmitz18-Jan-24 11:35
mveGerry Schmitz18-Jan-24 11:35 
GeneralRe: user data system for a web-based e-mail service Pin
Eddy Vluggen18-Jan-24 16:53
professionalEddy Vluggen18-Jan-24 16:53 
GeneralRe: user data system for a web-based e-mail service Pin
Richard Andrew x6419-Jan-24 12:06
professionalRichard Andrew x6419-Jan-24 12:06 
GeneralRe: user data system for a web-based e-mail service Pin
Gerry Schmitz19-Jan-24 13:24
mveGerry Schmitz19-Jan-24 13:24 
GeneralRe: user data system for a web-based e-mail service Pin
trønderen19-Jan-24 14:31
trønderen19-Jan-24 14:31 
PraiseRe: user data system for a web-based e-mail service Pin
Eddy Vluggen10-Feb-24 10:12
professionalEddy Vluggen10-Feb-24 10:12 
AnswerRe: user data system for a web-based e-mail service Pin
Richard Deeming29-Jan-24 4:03
mveRichard Deeming29-Jan-24 4:03 
GeneralRe: user data system for a web-based e-mail service Pin
Eddy Vluggen10-Feb-24 10:14
professionalEddy Vluggen10-Feb-24 10:14 
QuestionSilly Logging Question Pin
Kevin Marois27-Dec-23 17:05
professionalKevin Marois27-Dec-23 17:05 
AnswerRe: Silly Logging Question Pin
Mircea Neacsu27-Dec-23 17:32
Mircea Neacsu27-Dec-23 17:32 
AnswerRe: Silly Logging Question Pin
jschell28-Dec-23 6:25
jschell28-Dec-23 6:25 
QuestionImplementing domain driven design Pin
Jan Hein de Jong23-Dec-23 10:41
Jan Hein de Jong23-Dec-23 10:41 
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
  4. Hook is a (local) entity
  5. 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 work very independently. However, this means he can't depend on concrete implementations for his unittest, so he has to create mock implementations of the classes. Is this good practice, or just a lot of overhead?
AnswerRe: Implementing domain driven design Pin
Gerry Schmitz24-Dec-23 6:34
mveGerry Schmitz24-Dec-23 6:34 
GeneralWhy I don't do MVVM. Pin
Gerry Schmitz22-Dec-23 9:46
mveGerry Schmitz22-Dec-23 9:46 
GeneralRe: Why I don't do MVVM. Pin
Greg Utas22-Dec-23 14:46
professionalGreg Utas22-Dec-23 14:46 
GeneralRe: Why I don't do MVVM. Pin
jschell25-Dec-23 7:53
jschell25-Dec-23 7:53 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.