Click here to Skip to main content
15,904,877 members
Home / Discussions / Design and Architecture
   

Design and Architecture

 
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 
GeneralRe: Why I don't do MVVM. Pin
Greg Utas25-Dec-23 8:28
professionalGreg Utas25-Dec-23 8:28 
GeneralRe: Why I don't do MVVM. Pin
Dave Kreskowiak22-Dec-23 15:24
mveDave Kreskowiak22-Dec-23 15:24 
GeneralRe: Why I don't do MVVM. Pin
Gerry Schmitz23-Dec-23 7:30
mveGerry Schmitz23-Dec-23 7:30 
GeneralRe: Why I don't do MVVM. Pin
jschell25-Dec-23 7:55
jschell25-Dec-23 7:55 
GeneralRe: Why I don't do MVVM. Pin
Gerry Schmitz25-Dec-23 11:35
mveGerry Schmitz25-Dec-23 11:35 
GeneralRe: Why I don't do MVVM. Pin
jschell26-Dec-23 4:37
jschell26-Dec-23 4:37 
GeneralRe: Why I don't do MVVM. Pin
Gerry Schmitz26-Dec-23 7:03
mveGerry Schmitz26-Dec-23 7:03 
GeneralRe: Why I don't do MVVM. Pin
jschell27-Dec-23 5:19
jschell27-Dec-23 5:19 
QuestionLiterature on designing and implementing an access control system Pin
D4rkTrick8-Dec-23 2:17
professionalD4rkTrick8-Dec-23 2:17 
AnswerRe: Literature on designing and implementing an access control system Pin
Richard MacCutchan8-Dec-23 2:52
mveRichard MacCutchan8-Dec-23 2:52 
GeneralRe: Literature on designing and implementing an access control system Pin
D4rkTrick9-Dec-23 4:52
professionalD4rkTrick9-Dec-23 4:52 
GeneralRe: Literature on designing and implementing an access control system Pin
Richard MacCutchan9-Dec-23 5:05
mveRichard MacCutchan9-Dec-23 5:05 
AnswerRe: Literature on designing and implementing an access control system Pin
jschell8-Dec-23 4:49
jschell8-Dec-23 4:49 

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.