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

1NF vis-a-vis Business Rules

A practical way to think of 1NF in the above table is to ask a series of questions about the relationships that records (rows) can have between entities (tables) or attributes (columns), based on given business rules or constraints. For example, could a Subscriber record relate to many Email Address records? Could an Email Address record relate to many Subscriber records?

 http://en.wikipedia.org/wiki/First_normal_form

DCA Components

[T]he ... DCA paradigm ... explicitly describes high-level system features. The object space is partitioned into Components, where a component is an encapsulation of a number of domain objects. A component is characterized by its provided and required operations; its internal structure is invisible from its outside.

http://heim.ifi.uio.no/~trygver/2006/09-JavaZone/mvc-dca.pdf - Contrasts DCA with MVC