Software Architecture Design Decision

Our today world rounds around a digital core, where any part of human and business needs are available on digital platforms, this makes that a competitive world in which any success depends on the decisions.

Keeping that in mind and reflecting based on the competitive business and competitor actions is a natural part of history which is an exact matter of success, where we learn and practice to be one of the best.

The software design decision is not an exception and in other word is the exact core of business in this digital world. making software design decisions are the core of success.

What makes a software design decision a successful design?

• Changeability
• Adaptability
• Maintainability
• Business centricity
• …

A software design needs to be based on a well business context conducted by the business experts who knows better than developers and architects the business flows, they help to understand what that software needs to do.

Any well defined software can be a competitor if it can be easily maintained, adapted for new customer needs and evaluate easily based on business needs.

Well Defined Business:

A well defined software must be based on a domain or subdomain, a subdomain is a part of business domain where its core verbs and names can be noted in a single paper, if that will be more than that it will become a mess as soon as possible.

Understanding the core business domain of your software is practical and can not be based on other competitors version. if any part of competitor business can be discovered easily it will not be part of your core business which must be competitive, and if you focus on that core, shortly you will fail.

The observable business will never be your core business and can be any off-the-shelf solution you can use without investing a lot.

Now if your domain is partially well defined it’s time to tackle the software design decisions.

Software Domain:

A software must handle a part of business if no it will become as soon as possible a big ball of mud, it will not be easily adaptable, maintainable and you will suffer changing it.

A clarity in digital world is customer engagement and when you are engaged to your customers it will be hard to ask them for changing as you would like to change even for a positive reason, so the domain and context decision is a big part of your design.

The ideal decision will be a small context but if for any reason there is a need to have more than one domain or context, keeping the separation in software development will help in the future.

Architectural Design Decision:

The Software architecture is the main part of a successful software. before designing ask you some questions.

• Is there a need for audit?
• Is there a need of independence
• What is the level of inter-service communication?
• What are the dependencies?
• What is the level of consistency?
• What are the persistence data stores ?
• What is the transaction needs?

Let’s have a look at different kinds of software implementations.

Software Implementation:

A software can be implemented as

• Transaction script (Domain Logic Pattern)
• Active Record (Data Source Model Patterns)
• Domain Model (Domain Logic Pattern)
• Event Based Domain Model. ( Eventual Domain Model Pattern)

The Transaction Script is useful in scenarios where your domain is simple and it’s preferable to implement by procedures, in this kind of implementation we keep a very thin abstraction layer.

The Active Record is a practical exercise when the implementation has a small model which is driven by database schema, in active record you keep the model dependent to table row and the model will be responsible for interacting with database as inserting and updating.

The Domain Model is based on business domain and keeps aside the data persistence or any aspect out of domain exercise. We focus on States, Rules and invariant policies. The model presents the business expert storytelling and results the business model goal in its context. this implementation is ideal for complex business logic.

Event Sourced Domain Model acts exactly as Domain Model but presents a level of eventual consistency, in this implementation the strongly consistent level of model will be available after events projection, Inadvertently it will make separate the nature of Ingested models and read model. where a read model is a projection of all ingested events in whole entity life cycle. this implementation is ideal for complex business logic same as Domain Model but with a need of audit and traceability.

Software Architecture Patterns:

When designing software the architecture styles matters a lot and will play an important role in the Software development life cycle. the best decision of architecture leads you for a long-term gain.

The Software architecture design can be categorized typically as Layered , Business Application , Ports & Adapters ( Onion, Clean or Hexagonal) Or CQRS (Command Query responsibilities segregation) Architecture Patterns.

The Layered Architecture is a rolled in Design, where the dependencies are shared between to layers, any layer has a dependency to its lower layer. the typical layers are based on the responsibilities Presentation , Business , Database. This is useful for simple software with low domain complexities.

The Business Application Architecture is the exact as Layered Architecture but has more centralized focus on business layer, it’s a best practice to decouple business layer into Service and Business layers , that will help us to avoid presenting the cross cutting concerns of presentation layer which are best fit for business layer as exception handling and business state decisions. this way the business keeps focus on business without having the need to mix the business entities. this design is highly useful in BFF or multi context layered designs.

The Ports & Adapters Architecture is a style of layered architecture where the whole design is based on a core layer called Domain Layer, In this style the domain has the knowledge about Ports but is aware of adapter implementation or dependencies. Any inbound or outbound communication will be based on adapters. but the whole knowledge of domain layer will be the ports forever which are kind of communication contract and nothing more.

The CQRS Architecture is a pattern of architecture which focuses on separation of Commands and Queries model. and well why ? the goal is to separate the read model keeping its strongly consistent nature and giving the chance of being able to enrich the read model without making the read model entities stale cause of a lack of information temporarily, system failure or any kind of inconvenience. This pattern is a best choice when designing Event driven design software.

The Commands are messages which ask for an action and Queries are the read requests.

An Event is a message but within an specific State, this state typically is recalculated behind a command asking for action.

Conclusion:

When making a design decision we need to follow steps to obtain a viable design in which any evaluation or change in design which is conducted by business needs can be easily achieved and help us to the progression in term of productivity and delivery. a poor design can lead a fast start but very slow rhythm in the future and a error prune design.

If the business domain segregation leads into simple contexts the software design context will be as small as possible , if this single or twin context is a simple model the transaction script can be a well fit with layered architecture, choosing hexagonal patterns (ports & adapters) will not help you really as your domain evaluation is as small that will be changed rarely.

Imagine a context needs an audit by government and without that you will be eligible to pay a penalty. in this case your best choice will be a event sources domain model with a CQRS architecture design.

If your domain context has a high value in term on modeling and you need regenerating the data with new data models during the software life cycle, event your domain complexity is low , you need to consider the event sources domain model with CQRS.

Your software is highly attached to the data structure and your business experts , marketing and teams are speaking and your deadline is limited so no time to abstract a domain model, in this case the Active Record is the smartest decision with a layered architecture.