Architecting Your Enterprise for Business Agility

What is Business Agility?

Business Agility is the quality of an organization to respond to the changing environment, both internal or external, in a timely and cost-effective manner.

Read the full article here

What enables Business Agility in an Enterprise?

IT could play a significant role in enabling Business Agility in an enterprise. Followings are the three key enablers for business agility,

  • Hyper-awareness: ability to quickly detect and monitor changes in a business environment
  • Informed Decision-Making:  ability to make the best decision possible in a given situation
  • Faster Execution: carry out its plans quickly and effectively

Checkout CISCO’s mind-map for the Digital Business Agility enablers here.

What IT platforms are needed?

  • Big data
  • Agile Architecture

How does Big Data enable Business Agility?

Ninety percent of the total world’s data has been created in last two years, says IBM. In such a day and age of Data Explosion where quintillions of bytes of data is created every day, it would be criminal to not make use of it to enable business agility. These data could be monitored to bring about the hyper-awareness needed in strategizing business plans and could hugely assist the critical decision making process.

What does it take to build a Big Data platform?

Big Data is a dataset so large in its variety, volume, velocity and  that it is impossible to process them using the conventional database tools. The processing and storage needs of big data world are so different that standing up the platforms for it could be easily get beyond the reach of small or medium organizations. Cloud computing with its already built in state-of-art infrastructure to handle big data and could be inexpensive option for such companies.

What is Agile Architecture? How does it relate to Business Agility?

The architecture of an Enterprise needs to be re-organized such that Business Agility becomes and emergent quality of the Enterprise.

  • Micro-services: As a system of systems, an enterprise needs to look at itself as a collection of business components interacting dynamically with each other to provide a value stream. The more fine-grained these business components are, the more adaptive an enterprise as a system of systems would be.
  • DevOps: The cultural shift needed to build and run these fined-grained business components to maximize business velocity. CI/CD, IaaC, automated governance are some of the key components DevOps.

How about the up-front investment in building the platforms needed to support Agile Architecture?

There is definitely some up-front investment in bringing about the cultural shift and to stand up the infrastructure needed to support Agile Architecture. Bimodal IT, where the traditional IT co-exists alongside with the Cloud could be a good option. Most of the main-stream cloud providers have a rich set platforms available to support for agile architecture. Since no up-front cost for building and managing these platforms is needed, total cost of ownership should be evaluated.


Designing Value Objects with Entity Framework

As I burn my mid-night oil, trying to wrap my head around implementation strategy for Value Objects using Entity Framework, it so turns out that with Entity framework’s fluent API, it is ridiculously easy to do the same. But before we look at the implementation details of Value Objects using Entity Framework, let’s have few words about value objects.

Value Objects are small objects with no identity. Their values represent their identity. Hence, two Value Objects with equal fields are considered to be equal. Value Objects should be Immutable.

Let’s consider a Value Object called ProductPrice.

public class ProductPrice
  public double Amount { set; get; }
  public string Currency { set; get; }

Since we would like our value object to be Immutable, we will make the properties read-only and set them during the construction.

public class ProductPrice
  public ProductPrice(double amount, string currency)
    this.Amount = amount;
    this.Currency = currency;
  public double Amount { private set; get; }
  public string Currency { private set; get; }

As the name suggests, ProductPrice represents the price of the Product.

public class Product: IEntity
  public Guid Id { get; set; }
  public string Name { get; set; }
  public Price Price { get; set; }
  public Guid CategoryId { get; set; }

Since the product has only one price, it would make sense to have a single table for them. In order to do so, add the following in the DBContext,

public DbSet<Product> Products { get; set; }

Entity Framework will generate one table for you called Products with the following columns

  • Id
  • Name
  • CategoryId
  • Price_Amount
  • Price_Currency

With fluent configuration you can change the name of the columns, if you don’t like them. For example, I preffer ‘PriceAmount’ over ‘Price_Amount’, hence, I did the following to configuration to change the column name.

public ProductMap()
  Property(a => a.Price.Amount).HasColumnName("PriceAmount");

And in the DBContext class add the following,

protected override void OnModelCreating(DbModelBuilder modelBuilder)
  modelBuilder.Configurations.Add(new ProductMap());

And there you go. Simple, isn’t it?

Implementing Commands in DDD

Commands are one of the most fundamental building blocks of DDD. Commands represent the action that users try to perform on the domain model, they are the verbs in the domain model.

public class Order : IAggregateRoot
 public void PlaceOrder(PlaceOrder command) {}
 public void CancelOrder(CancelOrder command) {}


Since the command name is self-explanatory and sufficiently intention-revealing, we could just over-load the method with different commands.

public class Order : IAggregateRoot
 public void Handle(PlaceOrder command) { }
 public void Handle(CancelOrder command) { }


If you are a fan of Udi Dahan’s use of interfaces to make roles explicit in your code like me, then you could model each command as a role,

public class Order : IAggregateRoot, IHandle<PlaceOrder>, IHandle<CancelOrder>
 public void Handle(PlaceOrder command) { }
 public void Handle(CancelOrder command) { }
public interface IHandle<T>
 void Handle(T command);

One of the more popular implementation of command-handlers uses publish-subscribe patterns and it has some serious benefits. I would discuss that future post. However, the above implementation is a good elegant start to modelling commands in your DDD implementations.

Building Meaningful Audit Trail in your System

I have seen two primary approaches to building a audit trails for systems – entity level audits and property level audits.

Entity level audit maintains an audit log for every entity and makes an audit entry for ‘any’ operation done on these entities. Weather there is a change in one property of the entity or the entire entity changes as part of an operation that affects a bunch of other entities in the same transaction. At database level, this is often implemented using triggers that would copy the row being changed to an audit table along with some audit information.

Property level audit, on the other hand, goes to a different extreme and makes an audit entry every time any property on any entities changes. At database level this often translates into one big fat table which keeps track of any field in any table that has changed along with some general audit information.

Whiles these are two widely adopted implementation approaches for performing system audits, what both of these approaches fail to capture is the actual intent of the user. The granularity at which the system captures the audit data has an impedance mismatch with the business and it can get difficult to tell what actually was done to system to create this audit entry. Hence, these audit data would have a very limited business meaning and use.

Think about a modelling strategy where the actual operations that can be performed on the system are expressed explicitly. Wouldn’t it be a lot easier to just record these operations or the fact that these operations got performed on the system? This kind of audit data would have the granularity that would make sense to the business and creating a business meaningful audit reports out of such audit logs would be a lot easier. Isn’t it?

Implementing Repository in DDD – Part 1

Implementing Repository is fairly staright forward in DDD. There are generally two styles of implementation,
1. aggregate-dedicated repository and
2. generic repository.

An aggregate-dedicated repository will have a method per command or query; while, Generic repository will have a standard interface for every Aggregate. However, in both cases, the repository is suppose to operate at the aggregate-root level. This post will demostrate implementation of an aggregate-dedicated repository,

In your domain layer,
public class Order: IAggregateRoot
public Order(IOrderRepository repository)
{ ..}

public void Order(PlaceOrderCommand command)
public Order Get(Guid id)
return repository.Single(id);

public IList<Order> GetOrdersByCustomer(Guid customerId)
return repository.Where(o=>o.CustomerId = customerId);

Application Layer,

public class OrderService
public void PlaceOrder(PlaceOrderCommand command)
var Order = new Order(new OrderRepository());

The Application Layer uses dependency injection to inject an instance of the repository that the aggregate uses. The aggregate-root then calls the repository internally to persists the data and retrieve data.

In this style of implementation, a dedicated repository designed for each aggregate-root. This means a little more coding up-front compared to generic repositories, as there is one repository per aggregate. Writing unit-tests might be a little more difficult. But over all, the simplicity and flexibility that this implementation brings is huge and depending on your taste, choice of tech-stacks and data-access needs it might be a very good fit for you. Definitely worth a consideration.

Task Based UI

Task Based User Interface (TBI) is different from CRUD based User Interface in that the former tries to ‘mimic’ the business process lot more closely. TBI clearly identify the ‘tasks’ that the users perform in their day-to-day job and explicitly express them in the UI.

Some of the benefits of using TBI in business applications are as follows,

  1. TBI is more intuitive to the users as they tend to mimic the business process a lot better
  2. TBI can track the tasks that a user performs
  3. TBI tend to solve the problem of information overload.
  4. TBI requires the user to focus on what (tasks) needs to be done and not how should it be done, making it cognitively less demanding on the users.
  5. TBI appreciates that not all tasks in the business process has the same degree of complexity, significance and impact. Decoupling these tasks allow them to evolve orthogonally.
  6. Software development approaches like Domain Driven Development emphasizes on treating tasks (verbs of the domain model) as the first class citizens of the Ubiquitous Language

CRUD based UIs are agnostic of the aforementioned.

What do you think makes more sense in your case?

Reference, (task based UI section)

Aggregates in Domain Driven Design

Aggregate are cluster of objects that change together and are treated as a unit of transaction. Classic example of aggregate would be the Order class. Order contains Line-items. Line-items cannot exist and have no meaning without an Order. But, more importantly, Order and Order line-item must change together in an ACID fashion – either both change or none. in other words, Order and Order Line-items must always be consistent.

There is another kind of consistency that Domain Driven Design talks about that often creeps out a lot of developers, called the Eventual Consistency. With Eventual Consistency, the states between parts of the model are allowed to be in a temporary inconsistent state. The acceptable duration before which they must be brought to a consistent state is what is called the business Service Level Agreement (SLA). Talk to your business SMEs, you would be surprised to find out how many things in your model can be made eventually consistent.

In an aggregate, one of the objects (entities in DDD terms) becomes what is called the Root for the Aggregate. Aggregate Roots are the door-way to the aggregates. All objects in an aggregate must be accessed through the aggregate root. This ensures that loading, state-change and persisting of the entire aggregate happens as a unit and hence the transactional consistency is never compromised.

Another advantage of having a single point-of-access to all other objects in the aggregate is that the Aggregate Roots can internally access the states of different child object and decide if the requested state change will result in the valid state of the aggregate or not. Hence, they become a natural host for many if not most business rules related to the aggregates.

Even if you do not intend to use full-blown Domain Driven Design, identifying the portions of your model or object graph that change together and treating them as a unit of transaction can go a long way in taming the complexity of you application.