Define A Business Domain Context For A Web Service

Define A Business Domain Context For A Web Service

The service-oriented architecture (SOA) is back in vogue. What’s old is new again, but this time new technologies are available to make this more readily achievable. API management tools and microservice patterns foster greater business agility by enabling an organization to decompose their large monolithic applications into smaller units of highly reusable business domain information and logic that can be more quickly built, released, changed, and retired since far less development time and regression testing are required at all application lifecycle phases. Business data and logic can be slowly strangled out of a legacy application to be replaced by lightweight web service clients that communicate with a service gateway that provides access and security to your data and business processes via these small web services. Automated build and release tools facilitate rapid code deployment along with which you can develop a release approach that enables you to push out new code daily at almost any time of the day (you can even schedule fully automated deployments). So where do we start? Assess your business needs and pain points. Determine what would add the most value to your business services or processes that you could potentially find reusable across your department or organization.

For the purpose of this post, I will define my own business problem. For a long time now, I and my co-workers seem to have an issue with remembering all of the steps that we often need to repeat during the course of our project work. I personally think it would be nice to have a standard set of checklists and tasks to follow for the various workflows we perform. How about a web service that lets us create and manage reusable sets of ToDo lists?

As the product owner, I first need to create some product backlog items and write user stories.

Build a list of tasks:
As a person with a head full of experiences and possessor of tribal knowledge, I want to create a list of tasks that I can reuse time and again to help ensure I and my teammates perform all steps required in a typical work process.

Create multiple lists of tasks:
As someone who periodically repeats many different types of work processes, I want to create multiple different lists of tasks that I can reuse time and again to help ensure that I and my teammates perform all steps required in multiple work processes.

Clone a list of tasks:
As someone who frequently repeats work processes, I want to clone any of my lists so that I may track my progress separately for each instance of a work process.

Manage my task lists:
As one of many potential users of a task list service, I want to be able to view and manage the lists I myself created so that I can more easily focus on my tasks.

Ok, these seem like a nice set of product backlog items for now. Yes, I know that I have not yet defined my data models, nor have I specified any acceptance criteria. After all, it usually takes a while to get your business subject matter expert (SME) to the discussion table to help you flush out this level of detail for the requirements, does it not? We can refine the backlog further as we venture along together on our agile journey.

In the next post, I will keep myself busy while I am waiting for the business SME to fit me into their busy schedule. I think I can get into some of the technical details now, so I’ll put on my solution architect’s hat and setup a baseline web service using ASP.NET Core WebApi.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s