The Franciscan Report

Aspect:

PROS:
- encapsulate changes in one place
- faster development time
- declarative programming
- crosscutting problems are solved
- compiler support
- debugging can be done like normal code with proper IDE

CONS:
- easily abused
- harder to follow
- required learning curve
- harder to maintain

Observer Pattern

PROS:
- easy to debug
- more obvious in domain where changes happen

CONS:
- creates more coupling to domains
- easier to introduce defects, since changes are done in multiple places
- needs to create framework
- runtime debug

The hardest coupling to deal with is database coupling for various reasons:

- it spans more than one system, a lot of time including legacy applications
- it spans more than one development group, creating organizational related issues
- it deals with enterprise data, make it that much harder to change, as data is less flexible than code for example.

as the result, people usually just accepted the fact of it and do nothing to ease the problem. notice i said ease, b/c
database coupling like any other coupling can't be eliminated fully. Like its counterpart, the code, database coupling
can be reduced by introducing encapsulation with another layer of indirection (the cure for most computer science problems)

When designing a database entity, it's preferable not to business related field to be the primary key of an entity. For example,
if we have a Customer entity, we should consider not to have SocialSecurityNumber as the primary key, but to create a CustomerNumber
as the primary key(surrogate key). This practice enables separation between business type field and database type field for a number
of benefits:
- hides database key from business users
- guarantee uniqueness of an entity within the database system
- promotes more flexibililty to the design ( ie. in the case of Customer, not everyone has SSN )
- it's more natural and simple ( ie. Address with AddressId as its primary key, instead of address name, city, state, zipcode, etc. )
- decouple business changes from db changes ( ie. changes related to business key, will force foreign key changes )

However, application should still query the business entities by its business key, afterall business logic shouldn't aware of the
existence of db key (thus decoupling the two)

What is Consulting?

Sometimes I disagree with Bruce in a few of his technical approach, but I agree wholeheartedly on his view.

The most important points to be a succesful consultant are:

- teach the client, and hopefully you are a good teacher and be able to leave the client at a specified finite time. (not infinite time)
- communication is the most important part of consultancy
- continuosly upgrading your skills so that you feel the pain first before your client feels it
- have a good network -> gives you future opportunity easier without having to hog down one client for extended period of time

The different about body shop work and consultancy:
- body shop usually doesn't have much says in technical decision being made by the clients
- body shop is not obligated to teach the client
- body shop should be cheaper
- body shop work can be done offshored

P of EAA: Data Mapper

Hibernate provides custom user type capability in UserType or CompositeUserType. Those classes provide
capability to map user domain type to database type, including any conversion that needs to happen. Other techniques involve querying data from other external resources such as LDAP, etc. thus frees up domain responsibilites from other non domain related concerns.

Also, in the spirit of Domain Driven Design, where domain sometimes relies on other external resources that will impact its properties, one can use this pattern during loading/saving of those properties cleanly