Click here to Skip to main content
14,022,693 members
Click here to Skip to main content
Add your own
alternative version

Stats

17.7K views
383 downloads
23 bookmarked
Posted 2 May 2017
Licenced CPOL

Application Architecture - Grab Fried Onion Rings And Throw Spear Into Onion Architecture And Domain Driven Design

, 5 May 2017
Rate this:
Please Sign up or sign in to vote.
This will cover how to use Domain Driven Design in your application according to the Onion Architecture. There are short descriptions about architecture Category / Style, N-Layer / N-Tier Architecture, Template Method Pattern and Facade Design Pattern.

Software Architecture

Readers of the Software Testing Topics - Application Architect, Developers

What Will You Know From the Topics

I know that you already know N-Layer, N-Tier architecture. I will show you how to implement Onion Architecture using Domain Derive Design. Anyway, the following concepts will be covered in this topic:

  • Architecture Category
  • Architecture Style
  • N-Layer Architecture
  • N-Tier Architecture
  • Onion Architecture
  • Domain Driven Design
  • Template Method Pattern
  • Facade Design Pattern

Let's Drilldown Basic Architecture Concept

Suppose you have finished a project; but, have you ever asked yourself what architectural style and design you have used for your components or application? The big difference between average work and excellent work is not only using the latest version of the technology but also choosing the right architectural style according to your requirements and scope. Architecture is the creation of a better software world. I know you already know that; so, no more words. Time to overview only few important terms first.

Architecture VS. Design

  • Architecture: All architecture is design; it is a plan for the structure of the component.
  • Design: All design is not architecture; it uses the architecture.

Architecture Category

Architectural Styles

Basic Terms Of Architecture

N-Tier VS. N-Layer

  • Tier indicates the physical separation of components. It could be different assemblies like DLL, EXE, etc. on the multiple servers or same server.
  • Layers indicate the logical separation of the components such as Data-Layer, Business-Layer, Presentation-Layer, etc.

Component-Based Vs. Tier/Layer Architectural Styles

Component-based" means "separation of concerns", whether those are:

  • Tire-Component means separation/deployment
  • Layer-Component means logical separation

Application Type

  • Mobile Application
  • Rich Client Application
  • Rich Internet Application
  • Service
  • Web Application
  • Hosted & Cloud Services
  • Office Business Application
  • Share Point Line Of Business Application

Key Points Before Choosing Application Architecture

This is the guide to get you started. Always, you have to consider these points like below:

  • Application Type
  • Deployment Strategy
  • Appropriate Technologies
  • Quality Attributes
  • Cross-Cutting Concerns

Story Of Fried Onion Rings

I have very minimal knowledge about cooking. Most of the time, I buy food from the restaurant. Few months ago, I moved from one state to another state because of my job. One day, I was hanging out with one of my colleagues whose name was Christopher Robin. We had a long conversation. That's how he knew that I have very little knowledge about cooking.

So, once he offered to teach me - how to fry Onion Rings. Now I want to share the technique with you that I have learned from my colleague. So that you can start frying the onion-rings easily. Before start, you need to have an initial knowledge about:

  • Onion Architecture
  • Domain Driven Design(DDD)

Even-if you don't know that, then rock-a-bye, bye; don't worry about it.

How To Fry Onion Rings

Application Design

Although, in this design, I'm following the Domain Driven Design, I'm avoiding complexity just to keep it simple.

Domain Driven Design (DDD)

Focus Points Domain Core

  • Domain Models
  • Domain Services
  • Application Services

Domain Core into the Onion Architecture

In this diagram, each of the circles of the onion means a layer. So, according to the Onion Architecture, your domain model layer (say, entity layer) should be placed into the core or center of the onion.  

The very next layer of the onion core is the domain service layer. In this layer you can put all of the domain related logic services.

The outer layer of this diagram is known as the application services. In this layer we have to keep all of the service interface, abstract class and related classes so that other components (say, Data Access Layer) can implement their functionalities.

Domain Core In DDD

In this DDD diagram, the arrow symbol indicates the communication or the dependency of the layer. Application services and domain services are both have the dependencies to domain model. On the other hand, application services may use the domain services. These are known as the domain core.

Moral Points:

Architecture styles is telling you where you can place your application layers; but I'm not getting the direct answer from it that how I will implement the application. I mean how I will design my application.

Therefore, DDD will guide me about the design and how the layers of the application will communicate with each other's.

Designing Domain Core Of DDD

Identify And Create Domain Model

This central layer of the onion architecture defines the domain model and all of the outer layers will use these domain models. So, identify the following models for fried onion rings:

Models for Domain Core

  • Coke
  • Egg
  • Flour
  • Fried-Onion-Rings
  • Milk
  • Onion-Rings-Ingredients
  • Seasonings
  • Tray
  • Vegetable Oil

Identify And Create Domain Services

In this example, I'm not using any domain service and repository.

Identify And Create Application Service Interfaces

This layer defines the Interfaces of the services so that the outer layers can implement these interfaces. In this application service layer, I am placing all of the interfaces of the services.

Focus Points Infrastructure

  • Business Layer
  • Data Access Layer
  • External Service

Infrastructure Into Onion Architecture

The Data access layer, Business Layer and Services etc. are known as infrastructure layer according to this onion architecture.

Infrastructure Into DDD

Infrastructure Design

It could be your external Service (WCF, restful service), Business Layer (BL), Data Access Layer (DAL), etc. These are known as the infrastructure. This is just the outer layer of the domain core.

Business Layer Design

Look at the class diagram of the business layer (BL). I am implementing the required functionality of the BL from the application services. So, BL inherits the interfaces and abstract classes from the application services of the domain core and it also uses the domain models. In this layer, I have used two patterns and these are:

  • Template Method Pattern
  • Facade Pattern

Template Method Pattern

Template encapsulates the sequence steps of an algorithm.

In this example, I am going to show you how to fry the onion rings. So, if you want to fry this then we have to follow some of the steps and techniques. These are sequential and you have to maintain the order. You can't fry the full onion first and then can't clean the shell of the onion. Look at the below steps:

  • Step 1: Clean and wash onion
  • Step 2: Cut onion slices
  • Step 3: Get ingredients
  • Step 4: Put vegetable-oil into the frying pan
  • Step 5: Dip onion-slice into milk then into flour
  • Step 6: Carefully lower slice into Pan
  • Step 7: Carefully turn over golden-brown onion-rings

We can think of each of these steps as separate operations. I mean if we have 7 steps, then it means we need to implement 7 methods to complete the process and you can't ignore the order of the steps.

Template method design pattern gives you the facility to implement all of these 7 steps. Because here, you can create the abstract methods for each of the steps and finally it has a template method to call all of these steps sequentially.

Facade Pattern

Facade is usually used to mask the complexity of an entire subsystem of the layer. You can say that this is the API for other layers to communicate with it. So, another layer doesn't need to know anything about this layer except the facade class.

If you look at the other classes in this layer except the facade class, then we will find that I have used internal access modifier so that nobody can create any instance outside of this layer.

Data Access Layer Design

Similar to BL, I have implemented the required functionality of the data access layer from the application services. So, DL inherits the interfaces and abstract classes from the application Services of the domain core and it also uses the domain models. This layer will be accessible to another layer via the facade class.

Cross Cutting Concerns

 In this component diagram, each of the package folder like Log4Net, Configuration, Exception Handling, and Common Utility or Helpers etc. are known as cross cutting concerns. Generally, any components (BL, DL, PL) can access the crosscutting layers. It is common for all of the layers.   

In this component diagram I have placed them into packages of a component; but you can design them as a separate layer or components. It depends on the size of the application and if you want to re-use them.

Cross-Cutting Concerns Into Onion Architecture

In the Onion Architecture crosscutting concern is placed to the last outer layer.

Note that - in this application I have created the Configuration and Utility structure into the Cross Cutting project folder. But I did not implement anything there. Even-if I did not handle the exceptions or logging stuff. Because my goal to show you the structures of the application. So, I avoid the coding related stuff to keep it light.

Presentation Layer

Presentation layer (PL) or user interface will be placed on the outer layer of the onion architecture like infrastructure.

PL Into Onion Architecture

PL Into DDD

If you run the project (find the attachment), then you will see the output of the fried-onion-rings from the PL.

Whole Picture Of The Application

Finally, I can say that I'm not telling you that if you use DDD for your application, then it will be excellent. My main goal was to introduce you with the architectural style and design. That's why, I have escaped the principles, advantage, disadvantage and some other coding stuff.

If you start to implement any components of your application, then at-least think that if you follow any architectural style and design, then your software will be healthy. Nobody likes to stay overnight in the hospital with his/her application. So, the right design can help you to build better applications, improve endurance, and speed recovery.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

HR Rony
Engineer
United States United States
Motivated software developer in web/mobile application development, architecture design, and multi-layer implementation. Well-versed in multiple programming languages and platforms. Demonstrated success in UI, integration, and automated unit testing.

You may also be interested in...

Comments and Discussions

 
-- There are no messages in this forum --
Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web06 | 2.8.190417.4 | Last Updated 6 May 2017
Article Copyright 2017 by HR Rony
Everything else Copyright © CodeProject, 1999-2019
Layout: fixed | fluid