Integration Testing

We can still use the VSTS unit testing framework to write integration tests. The difference though, comes from the point of view that the test methods will not substitute in mocks for the dependencies, allowing the tests to run end-to-end testing a module/function of code right through.

 http://quickduck.com/blog/2008/02/18/unit-testing-mocking-and-dependency-injection/

Event Sourcing

"If you are using a structural model right now you are losing information"

Greg Young http://skillsmatter.com/podcast/design-architecture/architectural-innovation-eventing-event-sourcing/

Domain Objects

Out Domain Objects are purely behavioral. ... You will never, ever, ever have a setter on any of your domain objects. Domain Objects are not property buckets.

Gren Young http://skillsmatter.com/podcast/design-architecture/architectural-innovation-eventing-event-sourcing/

Singleton Anti-Pattern

Always ask for a reference! (don’t create, or look-up a reference in global space aka Singleton design anti-pattern) 

 http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/

Law of Demeter

Notice how the LoginPage violates this. It calls a new on User Repository. The issue here is that LoginPage is breaking a the Law of Demeter. LoginPage is asking for the Database even though it itself has no need for the Database (This greatly hinders testability as explained here). You can tell since LoginPage does not invoke any method on the Database.

 http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/

Policy.CurrentPeriod().Renew()
...There are a couple of problems with this approach. First, I'm clearly violating the Law of Demeter. A method M of an object O should invoke only the methods of the following kinds of objects: itself, its parameters, any objects it creates or instantiates, or its direct component objects.

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx - and goes on to explain how using Policy.Renew() ; i.e. invoking on Policy as the aggregate root is more expressive and less problematic.

DTOs are not Objects

A DTO is a representation of such a piece of data mapped into an object-oriented language. That still doesn’t make them objects in the sense of encapsulation. It would be impossible. Since all input is suspect, we can hardly enforce any invariants at all.

 http://blog.ploeh.dk/2011/05/31/AtTheBoundariesApplicationsAreNotObjectOriented.aspx

You usually can’t send the domain object itself, because it’s tied in a web of fine-grained local inter-object references. So you take all the data that the client needs and bundle it in a particular object for the transfer—hence the term.

Fowler http://www.drdobbs.com/errant-architectures/184414966

ORM vs. Repository

All other ORMs I've ever encountered are completely at odds with the Repository pattern. This goes for both L2S and EF, because they require not only that you derive from a particular base class, but also that Entities have default constructors. 

Mark Seemann http://www.manning-sandbox.com/message.jspa?messageID=105843