Reputation
4,190
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
8 16
Newest
 Nice Answer
Impact
~179k people reached

  • 0 posts edited
  • 0 helpful flags
  • 670 votes cast
Aug
24
comment Dependency Inversion Principle
Better suited for codereview.stackexchange.com ?
Aug
6
comment are technical user stories allowed in scrum
"Image storing and retrieving mechanism" shouldn't be a technical story but a developer task attached to your first user story.
Jul
6
comment What and how much domain code should be put in an F# module
Regarding microservices, he also said that the granularity would probably be more like multiple microservices in one BC. Anyway, I don't do microservices ;)
Jul
6
comment What and how much domain code should be put in an F# module
Good point about declaring design apart from the implementation. This can provide a high level view of a BC or aggregate and its ubiquitous language. Not sure how the gain in abstraction would benefit my domain however, since my rules are pretty concrete and literal. I more often found myself needing abstraction in peripheral plumbing code e.g. command handling, event management, etc.
Jul
6
comment What and how much domain code should be put in an F# module
@Grundoon I'm afraid I'm not allowed to show the code as it is. I'm not unhappy with the design I've got now, I was just hoping to find F# constructs that would match DDD delineations to facilitate the projection of a programmer's mental model of the domain onto the code and vice versa. I'm almost there with BC's as namespaces and Aggregates as modules. Thanks for offering though, I appreciate it.
Jul
6
revised What and how much domain code should be put in an F# module
Changed link to point directly to quote from the talk
Jul
6
comment What and how much domain code should be put in an F# module
I somehow feel that this could all be solved if we had partial modules as there are partial classes in C#. I haven't really had the time to look into why this isn't possible in F# though, so it might not be a good idea.
Jul
6
comment What and how much domain code should be put in an F# module
Absolutely, that's what I ended up doing. There's a trend though to consider Module = BC as a hard and fast rule -- I've heard it in other presentations and in conversations. Mark who commented on the question tweeted about it. Besides, I can understand why people take it at face value, because there's hardly a middle ground in this. It doesn't make much sense to say "a module is kind of a BC but you have to look at other modules to have a view of the complete BC". Better to have no rule at all then.
Jul
6
comment What and how much domain code should be put in an F# module
@bentayloruk Thanks for the tip. I ended up using 1 module per aggregate as a least-worst solution. Amount of code per file is still a big blocker for me --and it's only been growing since I asked the question. I must be different than most functional programmers in that regard ;)
Jul
6
comment What and how much domain code should be put in an F# module
@bentayloruk It's at vimeo.com/97507575#t=25m0s
Jun
22
comment Should a domain object wrap/contain a DTO interface?
It gets more tricky if the provenance follows no rule -- then you might indeed have to reflect provenance in the DTO itself.
Jun
22
comment Should a domain object wrap/contain a DTO interface?
I would first look for a business-related discriminator between those stores (e.g. all persons living in the US go in this store, others in that store) and let the application service call the correct repo based on that, but a more elegant solution would be to have domain events which the different data store adapters can listen to in order to decide if they'll persist to their store or not.
Jun
22
comment Should a domain object wrap/contain a DTO interface?
And I would definitely use fluent mapping over attributes if you can afford it, too.
Jun
22
comment Should a domain object wrap/contain a DTO interface?
I think you should refrain from introducing methods in that interface and classes though, they are not supposed to do anything. Even if attributes can be hints for an external tool, hydrating themselves is not their job.
Jun
22
comment Should a domain object wrap/contain a DTO interface?
Okay, I wasn't thinking about attributes. Seems legit to me then (except the name IPerson which sounds... awkward)
Jun
22
comment Should a domain object wrap/contain a DTO interface?
It should definitely be a class. The interface is useful when you have behavior and not just data, is it the case in your current implementation ?
Jun
22
answered Should a domain object wrap/contain a DTO interface?
Jun
11
awarded  Nice Answer
May
22
comment How do you avoid getters and setters?
@BenAaronson Yes, in the DDD sense which I think is the most common now. But you're right, according to Martin Fowler, "Early J2EE literature used the term value object to describe a different notion, what I call a Data Transfer Object. They have since changed their usage and use the term Transfer Object instead."
May
19
comment How do you avoid getters and setters?
@JacquesB A Value Object can have behavior and be more than a dumb data structure. It's an orthogonal concept.