Saturday, 22 June 2013

Self Encapsulation

What is Self Encapsulation?

Martin Fowler mentioned this in his bliki :

"Self Encapsulation is designing your classes so that all access to data, even from within the same class, goes through accessor methods."

This is also called Self Delegation. Take this simple Email example:

public final class Email implements Serializable { private static final long serialVersionUID = 1L; private String emailAddress; public Email(String anEmailAddress) { super(); this.setEmailAddress(anEmailAddress); } public Email(Email anEmail) { this(anEmail.getEmailAddress()); } public String getEmailAddress() { return this.emailAddress; } private void setEmailAddress(String anEmailAddress) { if(anEmailAddress == null) { throw new IllegalArgumentException ("Email address must not be null."); } if(anEmailAddress.length() == 0) { throw new IllegalArgumentException ("Email address is required."); } if(!java.util.regex.Pattern.matches( "\\w+([-+.']\\w+)*@\\w+([-.]\\w+)*\\.\\w+([-.]\\w+)*", anEmailAddress)){ throw new IllegalArgumentException ("Email address format is invalid."); this.emailAddress = anEmailAddress; } }

In above example, constructor is delegating instance variable, emailAddress assignment to its own internal property setter. Here the setter method is not only setting the email address, but also performing an important assertion. It is providing a guard against invalid data. The self-encapsulation enables the setter method to determine the appropriate contractual condition for setting the email address. This is the advantage of using Self Encapsulation.

2. Implementing Domain-Driven Design - Vaughn Vernon

Saturday, 8 June 2013

Template I follow in writing user story

User story one of the important item in your agile toolkit. A good user story will drive you to solve the right problem. I like writing user story. For me it is a discovery phase. Many unknown small but important requirements I have found when writing user story (some of my aha moments!!). Here is the template I follow when I write user story:

User Story:

Title: (one line describing the story)

As a {role} I want to {action} so that {benefit}

Notes (or Scopes):

Add any relevant background information, specific algorithms or formulas, conversation etc.

Acceptance Criteria:

Given {context/system status}
when I {input/action}
then I should {result}

When I write the user story I think about the benefit or business value that I am going to add by implementing this feature. Even when my product owner writes the user story, I discuss the benefit of the feature with him. It gives me an opportunity to get a good understanding of the requirement. It also helps to find out the required definition of done.

Role helps me to find out my primary user. Sometimes I find it easily just by discussing with product owner, sometimes I talk to different stackholders to find it out. You may face the similar situation, just take time in your finding.

Action outlines the main flow of interaction which needs to be addressed.

Notes or scopes are optional for me. I may not need them always. When I work on a complex problem that requires further discussion. In these discussions I may come across many important information and references. I write them under this section for future references.

Acceptance criteria is another important part in my user story. In this section I write down the expected behaviour and corner cases. I review them with the product owner and tester. Acceptance criteria help me to reduce the ambiguity and at the same time I get the sense of done once I complete coding that meets the criteria. I write them in BDD (Given-When-Then) format. One thing to remember here, you may not have all accept criteria when implementation starts and also do not expect them to remain static. They may change and so adjust them accordingly.

Wednesday, 5 June 2013

DDD Note: Domain

Domain is a sphere of knowledge or activity. For instance, you go to your favourite superstore to buy some products. Superstore buys these products from different sources and sells them to its customer. This superstore has its own unique business knowledge and way of doing things. This understanding and its methods for carrying out its activities or operations is its Domain. If this superstore requests you to develop a software for them, then you will be working in its domain.

It is rare to find a business that has only one functionality. There are different functions that make a business successful. It is always good to think about each of those business functions separately as a Subdomain. So a domain consists of multiple subdomains. In our superstore example, we can say that it has four subdomains: Product Catelog, Orders, Invoicing, and Shipping.

Some subdomains can be labeled as core domains. A Core Domain is a part of the business domain that is most important. The success of the business mainly depends on it. It deserves most of your attention and resources.

There are two other types of subdomains: Supporting Subdomain and Generic Subdomain. In many occasions you will find that there are services created or acquired to support the business. If it models some aspect of the business that is essential, yet not Core, it is a Supporting Subdomain. Supporting subdomains provide specialized functionality, whereas Generic Subdomain captures those activities that are not special but are required for the overall business solution.

Remember Supporting and Generic subdomains are not unimportant and they also deserve attention from you. But there is no need for the business to excel in these areas. It is the Core Domain that will provide distinct advantages to the business, hence it requires excellence in implementation.

  1. Domain-Driven Design - By Eric Evans
  2. Implementing Domain-Driven Design - By Vaughn Vernon