3,845 reputation
815
bio website
location
age
visits member for 4 years
seen 2 days ago

1d
awarded  Yearling
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
@dougajmcdonald it's unclear to me what you're asking. Does the problem lie in the fact that other developers working on unrelated stuff are hampered by these breaking changes ? Or that it takes time to get big reworks right (which there's honestly not a lot you can do about...) ?
Jan
21
comment Should a scrum team estimate time for the user stories during Sprint Planning, or before it?
Time is not the usual measure for user story estimation. It might be for tasks though. I recommend you update your question to reflect what you really mean by "estimate times for stories".
Jan
14
answered What is the definition of “technical debt”?
Jan
14
answered How to add new child entity to a repository in DDD?
Dec
2
answered Collections, relationships and tracking changes (in DDD)
Nov
20
revised IoC, Unity and passing parameters (or a way to avoid doing so)
added 1279 characters in body
Nov
20
comment IoC, Unity and passing parameters (or a way to avoid doing so)
It's much clearer with code :) See my edit.
Nov
20
revised IoC, Unity and passing parameters (or a way to avoid doing so)
added 1279 characters in body
Nov
20
comment DDD, modularizing the application and domain layers without breaking the DIP
@diegomtassis Level doesn't say anything about who consumes who. Coordinating is not a sign of higher level, IMO, but I admit this is debatable. DIP is not rocket science anyway, you should apply it with a grain of salt.
Nov
20
comment DDD, modularizing the application and domain layers without breaking the DIP
@diegomtassis Domain is higher than application because "It is the high level modules that contain the important policy decisions and business models of an application." (original DIP article, page 6) objectmentor.com/resources/articles/dip.pdf
Nov
20
revised DDD, modularizing the application and domain layers without breaking the DIP
added 37 characters in body
Nov
20
comment DDD, modularizing the application and domain layers without breaking the DIP
@diegomtassis The Domain is higher level and doesn't have a dependency on Application (edited my answer to reflect that). You are complicating yourself by trying to apply a principle where it doesn't make sense in the first place.
Nov
20
comment What and how much domain code should be put in an F# module
@MauricioScheffer you're the one making the claim, not me :) If you know that there's a function that does X but can't remember where it is, are you more likely to find it quickly in a 1000 LOC file or in a 80 LOC file ?
Nov
20
comment DDD, modularizing the application and domain layers without breaking the DIP
@DocBrown You're right. I edited my answer to better reflect that. I think it still respects the spirit of DIP though.
Nov
20
revised DDD, modularizing the application and domain layers without breaking the DIP
added 335 characters in body
Nov
20
comment What and how much domain code should be put in an F# module
@MarkSeemann I don't see a 2-aggregate BC as particularly big. Plus that would mean a separate library with a single file in it containing a single module ?
Nov
20
comment What and how much domain code should be put in an F# module
@MauricioScheffer "has absolutely no relation to the number of lines" -- do you have any link to research or something to back up that claim ? I have a visual memory so the longer the file, the more time it takes to find what I need. Plus it's a pretty common recommendation to keep code files reasonably short. Better a series of small labeled bags than a giant rag bag.
Nov
20
comment IoC, Unity and passing parameters (or a way to avoid doing so)
By entity I mean whatever object returned by the repository. Could be UserRepository, ArticleRepository, anything. But we may not have the same definition of repository. Why won't ResolvedParameters solve the problem ? What does this have to do with SPContext ? I guess without some code to explain it, the question is a bit blurry.
Nov
19
comment DDD, modularizing the application and domain layers without breaking the DIP
@DocBrown My first comment was precisely to say that the Domain is a layer of purely concrete classes (well, at least 80% of it). You're basing your answer on the 20% that is not representative of what the Domain is. There's no point in abstracting a BlogPost, an OrderLine or a CargoShippingRoute.