Book Review: Leading Change

John Kotter
Leading Change

Leading Change is a practical guide to implementing change in a corporate business environment. It is essentially a change process consisting of 8 main stages:

  1. Establish a sense of urgency and overcome complacency.
  2. Create a strong guiding coalition.
  3. Develop an inspiring vision and strategy for achieving it to help employees take actions in the right directions.
  4. Communicate the vision in a simple and clear message.
  5. Empower employees to experiment with how to make the vision a reality.
  6. Generate and celebrate short wins.
  7. Consolidate gains and produce more change.
  8. Anchor new approaches in the culture.

Today's changing market conditions put pressure on businesses to adjust their operations quickly to the new business environment. Companies unable to implement change quickly fall behind their competition.

I recommend this book to business and technical leaders at all levels of the organization. Whether you are considering a small change on your project, a technology improvement, or a system-wide business transformation initiative, you can apply principles described in this book in your situation. Happy reading!

June Architect: Domain Model Structure - Part 5: Loading Value Objects into Memory

In my last article, we talked about Value Objects, domain model elements with no conceptual identity. We said that Value Objects represent descriptive aspects of the domain and are fully defined by their state. This month, we will review the options for loading Value Objects into memory.

Potluck Principle of getting Value Objects

The Potluck Principle states that if you need to obtain a Value Object in your code, you have the following three options:

  1. You may be able to create the Value Object yourself
  2. You may be able to ask another object to give the Value Object to you
  3. You may be able to reconstitute the Value Object from a previously stored state

Option 1: Create Value Objects yourself

You can create a Value Object by calling it's constructor or factory. This is a very simple method but there is a catch: since Value Object are immutable, you need to know all their required attributes at the moment of construction.

Example: Creating an instance of the Address class based on a submitted HTML form.

Option 2: Ask other objects to give Value Objects to you

If you need a Value Object in your code, who could you ask for it? Since Value Objects are often descriptors, you may be able to query objects their describe (usually Entities or other Value Objects).

Example: asking Person Entity for the Person's Age or asking Email Address Value Object for it's Domain.

Another popular way is to obtain a Value Object as a result of an operation call closed under the Value Object interface.

Example: (new Money($10)).Multiply(2) results in new Money($20) or Color.Blue.Mix(Color.Yellow) returns Color.Green.

Option 3: Recreating a Value Object from a previously stored state

As discussed in my previous posts, Value Objects are tracked only as part of Entities they describe, in which case they are loaded into memory using Option 2. Value Objects are not recreated from previously stored states.

However, there is a situation when Value Objects need to be created independently. For example, it is a fairly common requirement to display the list of Value Objects in a drop-down list.

Example: User submits a new Purchase Order. As part of the entry screen, the user chooses Billing and Shipping Address for the new Purchase Order. All 50 States are selectable on the Billing Address form, but only 48 States are selectable on the Shipping Address form.

How shall we populate drop-down lists of 48 and 50 States for the New Purchase Order screen?

I have heard software designers making arguments towards promoting State to an Entity. Then, State Repository would be responsible for retrieving the right lists of States to display in each situation. I disagree with such design. It introduces a responsibility of managing States into the domain model, which can be easily avoided if we keep States as Value Objects.

Another important point against introducing the IStateRepository interface is that business rules of whether to display a particular State in a drop-down or not do not belong to the State class. For example, the company could introduce a new Product, which could be shipped to all 50 States.

My preference is to assign the responsibility of knowing about Value Object lists to aggregate repositories. In our example, IPurchaseOrderRepository would have FindStatesForShipping and FindStatesForBilling methods.

Happy coding! To be continued...

Welcome to ModelBlog

Thank you for visiting ModelBlog. We hope the time you spend with us will be both entertaining and worth your while. Have fun!