1

Looking to step into the world of Domain Driven Design with a simple project for my personal use. The project is a simple calculator to evaluate different retirement scenarios between the old DOD "High-3" retirement and the new "BRS" retirement.

The issue I'm having as I go through this (very simple) project is that I cannot identify any object that really has a unique identity. The Ubiquitous Language consists of: Retirement, Employee, TSP, High3, BRS, Contribution, etc. But none of these really have any GUID.

In most applications, an employee probably does differ from another employee or a retirement does differ from someone else's retirement. But for this project, a retirement with one set of attributes should be considered the same as another retirement object with the same set of attributes.

Or maybe I should view that the set itself (of attributes) is considered unique and, therefore, there can only be 1 set of attributes for a retirement.

Am I thinking about this incorrectly or is this not a good project for DDD? Again, I wanted to expand my design and architecture knowledge with a homemade project.

5

If I understand well your domain, you do not calculate a specific retirement of an identified employee who has paid well identified contributions, but you do a simulation for a generic employee that is solely defined by parameters relevant for the simulation.

In this case, your objects are indeed not entities with an ID, but "anonymous" value objects.

However, perhaps you need keep trace of all these value objects of a simulation scenario so that you can retrieve it later later. In this case, you'd have an entity Scenario with an ID. This entity would be the root of an aggregate that contains all the other objects.

If the goal is to learn DDD, this example is not very representative of the usual challenges and the many question that arise when modeling entities with complex relationships.

2
  • That's kind of what I was thinking. I figured DDD did not apply well to simulations. I do think a Scenario object is something that I was missing; however, it is my understanding that this would fall more under the Application Layer and not under the Domain Layer. Is this correct? – keelerjr12 Dec 7 '17 at 22:45
  • @keelerjr12 No, IMHO the scenario is part of the domain of simulations. If you don't need the scenario, because you just want to do a simulation with the current value objects, you would consider this as a ddd service (i.e. a domain responsibility that doesn't really belong to any entity/value object) – Christophe Dec 7 '17 at 23:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.