0

I am try to learn DDD, so bear with me please. Let say I have an aggregate called Issue. It has a StatusId property. This status can be ie. Open, Closed... and it is stored in a database table called Statuses. (this is because specific user can have specific statuses, so I want the user be able to add new statuses) Now, I have crated a method like this in the Issue aggregate: public static void SubmitIssue(Guid projectId, string issueTitle, string description...)

this method Creates new Issue with the req. params and after that I need to set it into the correct state. But the state is specified in the DB. How to handle this scenario when I must get the data from the DB when doing business logic that must not be couplet do the database access at all? Please help

Luka
  • 4,075
  • 3
  • 35
  • 61

1 Answers1

0

Your problem is a little more than just a DDD one. It is really about OO design. The problem is that you do not want an enum that will force you to make decisions all over the place. -Littering code with ugly switch and if statements.

There is no easy or precise answer to this.

What I would try to do:

You have Issue class (that can be different types) which means you could inherit and implement concretes based on that type. Important though! If the Issue can change from one type to another, inheritance on the Issue class is the wrong route. In that case you need to move the logical differences of those types (and the business rules they apply) onto the IssueType class, and your Issue class will have to be constructed with the relevant IssueType.

Uncle Bob has a very nice example that is very similar to your problem that he discusses in his book: http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445

Of course he does not speak about the DB in the example, but that is kind of the point of DDD.

I have the PDF version so pages may differ slightly. :Pages 454 to 456 discusses the specific use case.

Really hope this helps somewhat. -almost wish I was working with you on this in a team and could solve it.

Eugène
  • 676
  • 5
  • 10
  • Hi, thanks for answering so quickly. Of course I will have multiple Issue types (bug, task, impediment...) but this is not the point here. not the point because Issue type cannot be changed once set (it's immutable). My problem is, than to solve a business problem like setting the Status of an issue to ie. Open or Closed or InProgress... i need a round-trip to the database to get its StatusID so I can sett it. Enum in this case would be a nice way, but then, users would not be able to add new statuses. – Luka Feb 18 '15 at 07:46
  • Although, to be able to use these new statuses I would still need to change code to implement the logic to handle these new statuses or put the entire workflow (state) management in the DB and this is what I will not do. – Luka Feb 18 '15 at 07:52
  • You won't need the extra round trip to get the status, with first load you can get it. -Kinda the point of DDD to make sure you populate the required Aggregate roots and their data so you can make decisions without unnecessary trips to DB. Setting status, yes you will eventually persist your entire change-set which would set the StatusId in the DB. I agree, your logic is explicitly implemented for each status. most ticketing systems (this sounds like a tracking cyctem like JIRA, Assembla etc) make you choose the rules for statuses. -lots of extra coding requried -which you dont want I gather. – Eugène Feb 18 '15 at 12:39