3,796 reputation
715
bio website
location
age
visits member for 3 years, 10 months
seen Dec 16 at 9:15

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.
Nov
19
answered IoC, Unity and passing parameters (or a way to avoid doing so)
Nov
19
comment DDD, modularizing the application and domain layers without breaking the DIP
@Docbrown Plus, if you move your Domain Services interfaces to an additional layer, you'll always have a top-level layer referenced by all others. Exactly like when the Domain layer is topmost.
Nov
19
comment DDD, modularizing the application and domain layers without breaking the DIP
@DocBrown Domain Services are rare. I'd say they represent 20% at most of all externally accessible objects living in your Domain Layer in a typical DDD system.
Nov
19
comment DDD, modularizing the application and domain layers without breaking the DIP
Disagree. Domain Entities are concrete, rarely abstract. Your repositories don't return abstractions. Entities are what the Application layer services manipulate in a typical DDD architecture, yet they don't violate SRP.
Nov
19
comment IoC, Unity and passing parameters (or a way to avoid doing so)
Under which conditions is it SharePoint instead of SQL ? As part of the normal application execution flow ? When you change something in the config file ? How far from composition point (Controller) is that SQL vs SharePoint decision made ?