F#, Xamarin, WPF, Test Automation

Specification as a Library (Vol.2)

Introduction

In the previous link, I started my saga to explain an approach for encoding a specification into a system itself. In this post, I will introduce the design phase for such an application.

Identifying Domains

We need the specification for the software that we’re going to build. Hence, with the specification, we can identify individual domains for the application. Personally, I view domains as subsystems. A subsystem should behave as its own isolated system, thus being ignorant to peer subsystems as well as the higher-level system that encompasses it.

Specification

Now let’s imagine that we’ve just received word that the application that’s to be built needs the following:

User can register an account

Once registered, a user can login and logout

Once logged in, a user can create their profile

A user can set their content

A user can subscribe to content from other users

A user can view their followers

A user can view the people that they follow

A user can unsubscribe from other users

A user can feature specific content of theirs

A user can feature specific topics that they provide content on

Design

Let’s divide and conquer this influx of requirements by organizing the above requirements into isolated subsystems.

Some of the requirements for the application involved user-session. Hence, a user should be able to login and logout of the application. What would be a good domain name to reflect those type of operations? Let’s create a domain called “Session” as in user-session.

Session

Login

Logout

I lightly touched on how I view a domain as a subsystem. Moving forward though, I will use the term domain in the place of subsystem. If we examine our Sessiondomain that we recently extracted from our list of requirements, we should notice a requirement that’s kind of related to our Session domain but is definitely a distinguished operation that should not be thrown under the umbrella that we call a user-session. Hence, before a user can login to a session, they must first have a registered account. Also note that registering an account requires much of the same data that’s required for logging into an account. Hence, both a login and a registration require a user’s credentials. Do we extract yet another domain that has just one behavior and requires the same data (i.e. credentials) that our session domain also requires?

The following would be our Registrationdomain using the questioned approach:

Registration

Register account

This new domain would be extremely small and as a result, appears out of place because it’s indirectly related to our Sessiondomain. Hence, both Registration and Session domains share much of the same language. Specifically, they both rely on user credentials and they both share responsibility for accessing the system. Therefore, perhaps we should define a new domain that encompasses system access responsibilities. Specifically, we can define a domain that merges a user’s registration with a user’s session. Let’s refactor the Sessiondomain and Registrationdomain into single domain named the Access domain.

Access

Registration

Register account

Session

Login

Logout

The other domains of the system could be exposed as the following:

Profile

Set image

Set topics

Edit account information (i.e. name, email, etc.)

Portfolio

Set content

Set featured topics

Set featured content

Subscriptions

Follow user

Unsubscribe from user

View followers

View subscriptions

Conclusion

So far we received a specification and as a result, established a proposal for business domains. This is a good first step for designing our system. Hence, we should identify business-level responsibilities and then identify the specific business domains that should handle those responsibilities. In addition, a maintainer should visually be able to quickly identify the domain of the system that requires updates based on an established hierarchy of libraries and files. I will later share how that can be accomplished. But first, how can we implement a domain’s responsibility and at the same time encode specification compliance as a foundation for our app’s implementation to rest on?

The saga continues…

Advertisements

Share this:

Like this:

Published by Bizmonger

Scott Nimrod is fascinated with software craftsmanship. He has been practicing software development since 2003. He’s a thriving entrepreneur, software consultant, blogger, and a wanna-be thought leader. He focuses on native application development and test automation. He was born and raised on the mean streets of Cleveland, Ohio and currently resides in Miami Beach, Florida. He has been featured on DotNetRocks as well as DeveloperOnFire.
Featured Guest:
* http://dotnetrocks.com/?show=1214
* http://developeronfire.com/Podcast/Episodes/scott-nimrod-craftsman-or-prima-donna
* http://joecolantonio.com/testtalks/82-scott-nimrod-software-craftsmanship-revenge-of-the-sdet/
Details:
Scott Nimrod is a Agile (F#, XAML) Developer / SDET focused on enterprise development, mobile, and test automation.
He has worked in Seattle, Cleveland, Miami, Tampa, Ft. Lauderdale, and the Philippines. He hopes to work abroad again in either Asia or South America.
He loves sharing what he has learned.
He can be reached at the following number:
440.376.5867
scott.nimrod @ bizmonger.net
View all posts by Bizmonger