HexigonAI

hexigonai

We created the in August 2020, and since then, we have worked on its optimization and improvements. NestJS boilerplate is a project that contains all necessary libraries and solutions like auth, mailing, etc. for fast-starting your project using a classic REST API approach. NestJS boilerplate Right now, this boilerplate has 1.8K stars on GitHub and got recognition and support from the developer community. Recently, we also published our new which is excellently compatible with the backend implementation, so please check it out. frontend boilerplate on React Motivation to Include Mongo Support PostgreSQL support was originally included in the boilerplate because of its reliability, data integrity, and active community. But for projects that require high speed of working with large data sets and high scalability, MongoDB is usually a better choice. So, we wanted to integrate MongoDB support into our project. Also, we’ve got a number of requests to include NoSQL DB support from the community members and coworkers who use this boilerplate. So, now it's done, and developers can choose between the document-oriented database MongoDB and the relational database PostgreSQL. Now, let’s figure out what would be better to use when setting up a new project. Of course, the question is not which database is better, because both databases are excellent, it all depends on the scope and goals of the application. Let’s dive into the details. If you need a relational database that uses complex SQL requests and works with most apps that support relational table structures, it’s better to choose PostgreSQL. For a scenario where a high level of security and high ACID compliance is required, then PostgreSQL is the best solution. If you need a reliable tool to handle complex transactions and analytics in applications that work with multi-structured, fast-changing data, then MongoDB is a good choice for your project. If you're running an application that you'll need to scale and need to be distributed across regions for data locality or data sovereignty, MongoDB's scale-out architecture will automatically meet those needs. If you need to know more about MongoDB vs PostgreSQL comparison, I recommend reviewing . this article In order to provide a good level of abstraction and to simplify work with MongoDB, we use - an object data modeling (ODM) library. It allows developers to define their data models using a schema-based approach and provides a rich set of features that simplify the process of working with MongoDB. Mongoose In addition to supporting basic CRUD operations and query functions out of the box, Mongoose provides a richer set of features for working with MongoDB, such as middleware functions, virtual properties, query builders, and schema validation. It allows developers to define the structure of their data, including the types of each field, and specify validation rules to ensure data consistency and integrity. Object Mapping between Node and MongoDB managed via Mongoose Implementation With Hexagonal Architecture To allow an application to uniformly manage batch execution scenarios separately from its end devices and databases, the hexagonal software architecture (aka ports and adapters architecture) introduced by Alistair Cockburn was used. In , he emphasizes that there is not much difference between how a user interface and a database interact with an application since they are both external connections that are interchangeable with similar components and interact with the application in equivalent ways. his article Therefore, we used this architectural approach in the project, and it allowed us to encapsulate the implementation details of the data source, thus implementing the support of 2 types of databases in the boilerplate. Let's take a closer look at the implementation. First of all, we create the User entity in the directory. users/domain export class User {
  id: number | string;
  email: string | null;
  password?: string;
  firstName: string | null;
  lastName: string | null;

  // ...
} Then, we create a port called . UserRepository export abstract class UserRepository {
  abstract create(
    data: Omit<User, 'id'>,
  ): Promise<User>;
  abstract findOne(fields: EntityCondition<User>): Promise<NullableType<User>>;
} In , we implement UserRepository for working with TypeORM. users/infrastructure/persistence/relational/repositories @Injectable()
export class UsersRelationalRepository implements UserRepository {
  constructor(
    @InjectRepository(UserEntity)
    private readonly usersRepository: Repository<UserEntity>,
  ) {}

  async create(data: User): Promise<User> {
    const persistenceModel = UserMapper.toPersistence(data);
    const newEntity = await this.usersRepository.save(
      this.usersRepository.create(persistenceModel),
    );
    return UserMapper.toDomain(newEntity);
  }

  async findOne(fields: EntityCondition<User>): Promise<NullableType<User>> {
    const entity = await this.usersRepository.findOne({
      where: fields as FindOptionsWhere<UserEntity>,
    });

    return entity ? UserMapper.toDomain(entity) : null;
  }
} And we create a module for working with TypeORM in . users/infrastructure/persistence/relational @Module({
  imports: [TypeOrmModule.forFeature([UserEntity])],
  providers: [
    {
      provide: UserRepository,
      useClass: UsersRelationalRepository,
    },
  ],
  exports: [UserRepository],
})
export class RelationalUserPersistenceModule {} Now, we do the same for Mongoose. @Injectable()
export class UsersDocumentRepository implements UserRepository {
  constructor(
    @InjectModel(UserSchemaClass.name)
    private readonly usersModel: Model<UserSchemaClass>,
  ) {}

  async create(data: User): Promise<User> {
    const persistenceModel = UserMapper.toPersistence(data);
    const createdUser = new this.usersModel(persistenceModel);
    const userObject = await createdUser.save();
    return UserMapper.toDomain(userObject);
  }

  async findOne(fields: EntityCondition<User>): Promise<NullableType<User>> {
    if (fields.id) {
      const userObject = await this.usersModel.findById(fields.id);
      return userObject ? UserMapper.toDomain(userObject) : null;
    }

    const userObject = await this.usersModel.findOne(fields);
    return userObject ? UserMapper.toDomain(userObject) : null;
  }
} And module for working with MongoDB. @Module({
  imports: [
    MongooseModule.forFeature([
      { name: UserSchemaClass.name, schema: UserSchema },
    ]),
  ],
  providers: [
    {
      provide: UserRepository,
      useClass: UsersDocumentRepository,
    },
  ],
  exports: [UserRepository],
})
export class DocumentUserPersistenceModule {} After that, we connect either the module for working with Mongoose (DocumentUserPersistenceModule) or TypeORM (RelationalUserPersistenceModule) in based on the ENV configuration. users/users.module.ts const infrastructurePersistenceModule = (databaseConfig() as DatabaseConfig)
  .isDocumentDatabase
  ? DocumentUserPersistenceModule
  : RelationalUserPersistenceModule;

@Module({
  imports: [infrastructurePersistenceModule, FilesModule],
  controllers: [UsersController],
  providers: [UsersService],
  exports: [UsersService, infrastructurePersistenceModule],
})
export class UsersModule {} And then, in the UserService, we can access the UserRepository, and nestjs will understand which database to use based on the ENV configuration settings. @Injectable()
export class UsersService {
  constructor(
    private readonly usersRepository: UserRepository,
  ) {}
} The full implementation can be found . here MongoDB Schema Schema was built with best practices for MongoDB for best performance and scalability. The Schema design for NoSQL databases is not the same as for relational databases. One of the differences is that in relational, we have the option to reduce your schema to normal forms to avoid duplicates, etc. While for NoSQL, we can duplicate data to avoid "joins", due to which the best performance indicator will be achieved during data sampling. Let's take a look at the boilerplate as an example to see what the difference is. The database schema for PostgreSQL looks something like this: And an example of a data table: Talking about MongoDB, we can NOT transfer the design experience from PostgreSQL here, that is, create 4 collections users, files (for photos), roles, statuses, and store in the user collection links to other collections, and during data sampling, using aggregation ($lookup) append additional data, as this will affect performance ​(read more about joins comparison , though 2020 year sounds old, but it is still actual). in this article What should the scheme look like? Everything is very simple: all data must be stored in one collection: And now, when we fetch users, we will not need to make additional requests to obtain data about the user's photo, role, and status because all the data is already stored in the user's collection, in fact, due to productivity increases. To learn more about designing MongoDB schemas, I recommend reviewing . this article How to Use NestJS Boilerplate With Mongoose For comfortable development (MongoDB + Mongoose), you have to clone the repository, go to the folder , and copy as . my-app/ env-example-document .env cd my-app/ cp env-example-document .env Change to DATABASE_URL=mongodb://mongo:27017 DATABASE_URL=mongodb://localhost:27017 Run the additional container: docker compose -f docker-compose.document.yaml up -d mongo mongo-express maildev Install dependency npm install Run migrations npm run migration:run Run seeds npm run seed:run:document Run app in dev mode: npm run start:dev That's it. If we talk about the impact of the selected database on the frontend application, in particular the , which we also maintain up-to-date and plays well with the currently discussed , it won't have an effect on their interaction. Extensive React boilerplate NestJS boilerplate Whatever database you choose to use - PostgreSQL or MongoDB (they are both great), the choice should depend on the whole project, and in our boilerplate, you have that choice. So, you are welcome to try it if you find it useful, and don't forget to click the star at the library ⭐. Full credits for this article to and 🇺🇦 Vlad Shchepotin Elena Vlasenko

MongoDB Support for NestJS Boilerplate With Hexagonal Architecture

Discover how the , a clean architecture pattern also known as Ports and Adapters, can help! Did you ever face problems when comes the time to upgrade the stack of your software? Are you able to distinguish your functional tests from your integration ones? Migrating your legacy means rewriting everything from scratch? Hexagonal Architecture Business logic overboard! In a previous experience, my team had to port an old application on a brand-new stack. The software was moving from an EAR/SQL app to a self-contained JAR using NoSQL. By studying it, we quickly realized that we had to redo the entire infrastructure. In fact, the only thing that didn’t have to change was the business logic. So, it makes sense to reuse it, right? After a deeper look, the maven module named model was POJOs with only getters and setters, totally … Although there is also service module, the business logic is shared across all the layers. It was drowned in a lot of technical code such as DAOs creation, Serialization, etc. There were no ways to extract the business logic! Some parts of it were relying on the technical behavior of the old framework we tried to remove. And why? Because there was no clean separation between the business logic and the technical code. anemic Separation of concerns: isolating the business logic The Hexagonal Architecture created by ensures the re-usability of the business logic by making it technical-agnostic. So, changing the stack will have no impact on the domain code. Alistair Cockburn One key concept of this architecture is to put named the Domain. Let’s update the previous schema: all the business logic into a single place Important constraint: ; this is the only way to ensure that the business logic is decoupled from the technical layers. How do we achieve that on the previous schema? The domain clearly depends on the persistence layer! Well, by using a pattern you may know: the inversion of control. By calling the domain the Hexagon, it will look like this: the domain depends on nothing but itself The inversion of control was pretty magic, let’s see later how it works. Now you got an overview of what is the Hexagonal Architecture: Only two worlds, inside and outside the Hexagon. , meaning all your technical code. Inside: all the business logic Outside: the infrastructure — . It ensures the isolation of the business domain from the technical part. The dependencies always go from outside toward the inside of the Hexagon One corollary of this is . And not only regarding your own layers: . That includes external annotations like Jackson or JPA. the Hexagon depends on nothing but itself It must not depend on any technical framework No frameworks allowed in the domain (almost) Let me explain you a bit more the last point, which is a really important one. In another experience, my team had to port an application from the “classic” Spring framework to Spring Boot. The main (painful) problem we had: leveraging too much on the Spring Integration Tests to validate our functionalities. Furthermore, those functionalities were also too coupled with Spring. At the first try of our Spring Boot migration, all functional tests were failing. We were not able to determine if the business logic was broken somewhere or if the reason was purely technical. We eventually figured out that it was an integration problem at test level. So we fixed all the tests one by one by crossing our fingers… Hoping the domain was still correct. No framework used in the Hexagon means . It will as well since you no longer mix it with integration issues. And at the end, you’ll do thanks to this constraint of the Hexagonal Architecture. This way the functional tests will directly interact with the Hexagon and only with it. the business domain can be reused regardless the change of the technical stack increase the testability of your domain real functional tests NOTE: In Maven, you can ensure this constraint using the . enforcer plugin The Hexagonal Architecture Inversion of Control Remember the inversion of control? To ensure the isolation of the Hexagon, the dependencies on downstream layers have been inverted. The trick is in fact pretty simple as you can see: The outside of the Hexagon (the infrastructure) is divided in two virtual parts, the left side and the right side. On the left, you got everything that will query the domain (the controller, the REST layer, etc.). And on the right, everything that will provide some information/services to the domain (persistence layer, third party services, etc.). Protecting the domain with an anti-corruption layer To let the outside to interact with the domain, the Hexagon provides divided in two categories: business interfaces The gathers all the interfaces for everything that needs to query the domain. Those interfaces are implemented by the Hexagon. API The (Service Provider Interface) gathers all the interfaces required by the domain to retrieve information from third parties. Those interfaces are defined in the Hexagon and implemented by the right side of the infrastructure. We will see that on some circumstances, the Hexagon can also implement the SPI. SPI There are two important facts here: The API and the SPI only manipulate domain objects of the Hexagon. It indeed ensures the isolation. The API and the SPI are parts of the Hexagon. In a layered architecture, . In the Hexagonal Architecture, the domain only handles domain objects. Consequently, the persistence is in charge to translate the domain objects into any “DAOs” to be persisted. This is what we call an adaptation. the Business Object or the service usually creates the DAOs In a layered architecture, . In the Hexagonal Architecture, the domain only handles domain objects. Consequently, the persistence is in charge to translate the domain objects into any “DAOs” to be persisted. This is what we call an adaptation. the Business Object or the service usually creates the DAOs The modularity strength of the Hexagonal Architecture As mentioned above, the architecture is another name of the Hexagonal Architecture. It comes from . Because everything is decoupled, you can have a REST and JMS layers in front of your domain at the same time without having any impacts on it. Ports and Adapters the power of the modularity of this architecture On the SPI side, you can change from a MongoDB driver implementation to Cassandra if needed. Since the SPI won’t change because you change the persistence module, the rest of your software won’t be impacted. The API and the SPI are the Ports and the infrastructure modules using or implementing them are the adapters. How to implement the Hexagonal Architecture? One more rule here: . This will bring you a lot of advantages: always start with the inside of the Hexagon instead of the technical details. Because only the feature brings value to your company. A developer working on another business domain is able to put in place a Spring Controller. But the double declining balance method will sound like Wookiee for him unless he worked for an accountancy company. Focus on the feature Sometimes it’s really hard to know which technical implementation you really need at the beginning. Consequently, delaying this choice helps you to focus on what brings the primary values to your company — the feature. Furthermore, after the implementation of the business logic, some new elements can help you to make the best choice regarding your infrastructure. You can discover that the domain is more relational than expected, so SQL is a good choice for your database. Delay choices on technical implementation. One corollary is it ensures the . Since you should never write code without tests, it means that the . Furthermore, we got here real functional tests focusing on the business only. Hexagon is a stand-alone Hexagon is self-tested A Test-Driven implementation With the Hexagonal Architecture, you put your functional tests in your domain. Those tests will call directly the domain API while avoiding any disturbance from the technical part. In a way you are creating an adapter simulating the Controller to test the features of the domain. My advice is writing your functional scenario first using the to describe your feature. Starting with the functional tests of the Domain Behavior-Driven Development The first step of the . And write the API interface which will be the entry point of your feature. Then implement your tests with TDD and finally implement your business logic. While writing it, you might need to retrieve some data from the database for example, so create an SPI. Since the right side is not yet implemented, create a stubbed implementation of this SPI inside your Hexagon. That can be achieved using an in-memory database implemented with a Map. “double-loop” will produce your functional test using ATDD You can choose to keep the Stubs in the test scope of your application. But you can as well temporarily ship it if needed. For example, once we made the first feature on the Hexagon, we stubbed an external service and the database. Because our client needed us to provide an interface contract, we secondly exported the domain through a REST controller. So we shipped a first version with stubbed data on the right side of the infrastructure. This way, the client was able to see the structure of our data and the expected behavior of the feature. It was much more reliable than creating by hand some JSON samples of our requests and responses because it actually deals with real business constraints. Finishing with the adapters The next step is usually opening the left side first. This way you can put in place some integration tests on the feature. At this time you can provide and ensure an interface contract with your clients. some live documentation Finally, open on the right by implementing the SPI of your feature by taking advantage of the integration tests. I strongly recommend your tests to be stand-alone to avoid any instability during build time. You should always mock your third parties using something like for external services or to simulate a MongoDB. Wiremock Fongo Loop the same way for your other features. For more information, an is available on GitLab. Hexagonal Architecture Testing Strategy Hexagonal Architecture in a nutshell So, now we have seen what is Hexagonal Architecture! There is a real benefit in . It ensures your business domain is regarding the continuous evolution of the technology. decoupling the business logic from the technical code durable and robust The Hexagonal Architecture offers you a real means to achieve this by: Putting all the business logic in a .The domain is regarding the technical part because but itself. That’s why single place isolated and agnostic it depends on nothing the dependencies always go from outside to the inside of the Hexagon. The Hexagon module. Thus, It of your domain by writing which don’t have to deal with technical issues. is a stand-alone increases the testability real functional tests This architecture offers a . It helps you to write as many adapters as needed with a low impact on the rest of the software. And since the domain is agnostic from the stack . powerful modularity , the stack can be changed without any impact on the business By , you ensure to bring value to your customer by . This way you can to make the best choice at the right time. always starting with the domain focusing on the feature development delay choices on technical implementation Some feedbacks Hexagonal Architecture is not suitable for all situations. Like Domain-Driven Design, this is really applicable if you got a real business domain. For an application which transform a data to another format, that’s might be overkill. To finish on this, always be pragmatic when you adopt a new technology. As stated before, , but exceptionally you can. For example, in our case the Hexagon had three exceptions: Apache Commons Lang3 (StringUtils), SLF4J and the JSR305 of Findbugs. Because we didn’t want to create the wheel since those frameworks had very low impacts on the domain. One good side effect of the Hexagonal Architecture, is that you keep challenging yourself before integrating a new framework. By using this architecture, we reduced the number of dependencies from fifty to only three or four for the domain. And this is very good from a security perspective. the Hexagon must not depend on any technical framework Further readings Want to go further? Checkout those And if you to see some code, you can now find on GitLab a Kotlin/Spring Boot . Domain-Driven Design and Hexagonal Architecture tips&tricks series Hexagonal Application

Hexagonal Architecture: the practical guide for a clean architecture

Software writing taught me that: a well written software is a simple software. So I started to think how to achieve simplicity in a methodological way. This is the first story of a series about this methodology. Naturally it’s a snapshot because it’s in constant evolution. Simplicity A definition of simplicity is: The quality or condition of being easy to understand or do. Oxford dictionary ( ) https://www.lexico.com/en/definition/simplicity So, a simple software is a software that is easy to understand. After all software are written by humans for humans. This implies that they should be understandable. Simplicity guarantees that its understandability isn’t an intellectual pain. A software solves a problem. So to build the former you should understand the latter. But to build a software you should understand - - a problem. simple clearly First step: architecture On the there is a deep definition of architecture and its explanation: Martin Fowler blog “Architecture is about the important stuff. Whatever that is.” On first blush, that sounds trite, but I find it carries a lot of richness. It means that the heart of thinking architecturally about software is to decide what is important, (i.e. what is architectural), and then expend energy on keeping those architectural elements in good condition. Ultimately the important stuffs are about the solved problem. In other words about the software domain. So we need an architecture that allows us to express - - the software domain. clearly I think that the hexagonal architecture (a.k.a. ports and adapter architecture) is an ideal candidate. It’s based on layered architecture, so the outer layer depends on the inner layer. Each layer is represented as a hexagon. Here a UML-like diagram to express the below concepts: In this architecture the innermost hexagon is dedicated to the software domain. Here we define domain objects and we express clearly: what the domain does as input port or use case (I prefer the latter because expressiveness). what the domain need, to fulfill use cases, as output port. Conceptually on the sides of the domain layer there are use case and output port interfaces. The communication between the outer layers and the domain layer happens through these interfaces. The outer layer provides output port implementations and they use the use case interfaces. The implementations and use case clients are are called adapter. Because they adapt our interface to a specific technology. This relation is an instance of the . Simply put: high level concept, the domain, doesn’t rely on a specific technology. Instead low level concept depends upon high level concept. In other words our code is dependency inversion principle technology agnostic. As you can see the concepts expressed in the outer layers are just details. The real important stuff, the domain, is isolated and expressed clearly. Code A little project accompanies this series to show this methodology. It's written in Java with the reactive paradigm from the beginning. For this reason the ReactiveX library is also used in the domain layer. The software analyzes the capabilities (e.g. the java version, the network speed and so on) of the machine and it exposes them through REST API. It’s inspired by a real world software that I wrote because of work. The first step is to define the innermost hexagon. We can already identify: the main use case, expressed as GetCapabilitiesUseCase the object that describe the machine capabilities, expressed as Capabilities The use case is an interface: (if you never used ReactiveX: a Single means that the method will return asynchronously an object or an error) { ;
} public interface GetCapabilitiesUseCase Single<Capabilities> getCapabilities () The Capabilities objects are immutable ). And there is an associated builder ( ): (precisely they're value objects I’m using lombok annotations to generate the code { String javaVersion; Long networkSpeed;
} @RequiredArgsConstructor @Value @Builder public class Capabilities private final private final Initially we just need to analyze two capabilities: java version, expressed as GetJavaVersionPortOut network speed, expressed as GetNetworkSpeedPortOut Here are the port out interfaces: { ;
} public interface GetJavaVersionPortOut Single<String> getJavaVersion () { ;
} public interface GetNetworkSpeedPortOut Single<Long> getNetworkSpeed () Finally we can define the implementation of the use case: { { Single.just(Capabilities.builder())
      .flatMap( ::getJavaVersion)
      .flatMap( ::getNetworkSpeed)
      .map(CapabilitiesBuilder::build);
  } { getJavaVersionPortOut
      .getJavaVersion()
      .map(builder::javaVersion);
  } { getNetworkSpeedPortOut
      .getNetworkSpeed()
      .map(builder::networkSpeed);
  } GetJavaVersionPortOut getJavaVersionPortOut; GetNetworkSpeedPortOut getNetworkSpeedPortOut;
} @RequiredArgsConstructor class Analyzer implements GetCapabilitiesUseCase @Override Single<Capabilities> public getCapabilities () return this this Single<CapabilitiesBuilder> private getJavaVersion (CapabilitiesBuilder builder) return Single<CapabilitiesBuilder> private getNetworkSpeed (CapabilitiesBuilder builder) return private final private final As said the outer layers communicate with inner layers through use case interfaces. For this reason I made the implementation as package private. In this way we . program an interface and not an implementation Nonetheless we need some way to return an instance of Analyzer to the outer layers. They will be in another package, so they cannot instantiate an Analyzer object. For this reason I usually define UseCaseFactory accessible by outer layers: { { Analyzer(getJavaVersionPortOut, getNetworkSpeedPortOut);
  }
} public class UseCaseFactory GetCapabilitiesUseCase public static getCapabilitiesUseCase (
    GetJavaVersionPortOut getJavaVersionPortOut,
    GetNetworkSpeedPortOut getNetworkSpeedPortOut
  ) return new Furthermore the factory improves expressiveness because it states clearly the use case dependencies. Conclusion For this story that’s all. As you can see from the code, the hexagonal architecture allows us to describe the important stuff - the domain - without any technological dependency. Obviously the programming language and the library for the chosen paradigm are excluded. The project is on and I'll update it following the stories. github Stay tuned! :D Useful resources Martin Fowler about architecture Uncle Bob about clean architecture Dependency inversion principle ReactiveX The Reactive Manifesto

Road to Simplicity: Hexagonal Architecture [Part One]

This article is for sharing my understanding about Ports & Adapters pattern (also known as Hexagonal Architecture), hoping it can be helpful to someone interested in this subject. Introduction Documented in 2005 by Alistair Cockburn, Hexagonal Architecture (is also called as Ports & Adapters  pattern ) is a architectural pattern used in software design that promotes decoupling from technology and frameworks. The hexagonal architecture is  an attempt to avoid known structural pitfalls in layered architecture. The  idea of Hexagonal Architecture ( Ports & Adapters pattern) is create loosely coupled application components that can be easily connected to their software environme to makes components exchangeable at any level  so that it could be run by different kinds of clients (humans, tests cases, other applications,…) it could be tested in isolation from external devices of the real world that the applica Pitfalls of layered architecture In layered architecture,  over a period of time all the projects get into the problem of excessive coupling across layers. Architecture Alistair Cockburn'a aim was to use architecture to prevent business logic from infrastructure or framework,He accordingly drew application domains as hexagonal shapes. Imagine a hexagon, here the hexagon is the application itself. Inside the hexagon we just have the things that are important for the business problem that the application is trying to solve. The hexagon contains the business logic, with no references to any technology, framework or real world device. In other word, in hexagon, anything inside the hexagon must be free from technology concerns,So the application is . technology agnostic we have any real world thing that the application interacts with. Outside the hexagon Overview of what is the Hexagonal Architecture with , Inside the Hexagon all the business models/logics outside the Hexagon: the infrastructure , which ensures the isolation of the business domain The dependencies always go from outside toward the inside of the Hexagon , s Hexagon depends on nothing but itself It must not depend on any technical framework Ports And Adaptors in Hexagonal Adapters Adapter is to implement a concrete protocol by which some external system or device can communicate with the application. An adapter translates between a specific technology and a technology free port. An is a software component that allows a to interact with a port of the hexagon adapter technology In most of cases, REST controller are act as a our primary adapter, providing endpoints  accessing domain through port (Interface) A converting a specific technology request into a domain understanding form and pass to the hexagonal through Interface( port) adapter Ports Ports are the application boundary, in the picture a port is an . edge of the hexagon To let the outside to interact with the domain, the Hexagon provides divided in two categories: business interfaces(Ports) Those interfaces are implemented by the Hexagon, are also called ' ' API : Inbound interface (Service Provider Interface)  is an interface for a functionality, needed by the hexagon for implementing the business logic. It also called SPI: outbound interface Befits of Hexagonal High Maintainability Low Technical Debt Easily incorporates any channels like sql, ftp, Http, Ftp, JMS, etc. Easily tested because it is easy to create a mock when there is a need to implement the contracts. Adding new requirements means adding plugins or implementing the contracts. Proper separation of concern. Conclusion This is my understanding about hexagonal architecture. In I would like to run through Use Case  using hexagonal architecture . Next Part If you want to get more information on the topic, read Alistair Cockburn’s original article on the subject I hope this article will help you understand idea of Hexagonal Architecture and who they are comes together I’ll be glad for any feedback!

Hexagonal Architecture: Introduction  Part I

First of all, if you didn't read the previous post, please read before you jump into this section first part Hexagonal Architecture: Introduction  Part I Today we are going to discuss about hexagonal archittecture with use case There three basic components which hexagonal architecture talks about. Application (Domain Model) Ports Adapter Application Hexagon is the application itself. Inside the application we just have the things that are important for the business problem that the application is trying to solve. Ports Ports are the medium through which business logic is accessed.Port is a use case boundary i.e. Ports correspond to use-cases in the application Adapters An adapter translates between a specific technology and a technology free port. Adapters is medium which serve the purpose of transforming the communication between various external actors and application logic through port. In hexagonal architecture all  actors interact with the application through adapters User Case Consider Loan Application use case. A customer wants to apply for a loan application using online website or using an ATM. Application then verifies the credit rating check system,updates information in database and sends an update mail to the customer Hexagonal Bondries are ApplyForLoan CheckCreditRating SaveCustomerInformation SendEmail Port (API): LoanApplication  Port (ApplyForLoan) Port (SPI): Credit Rating System Port (CheckCreditRating) FTP Port (SaveCustomerInformation) Notification Port (SendEmail) Adapters: Load Application Adapter (Assuming ATM machine interacts with the banking system using a REST API ) Credit Rating System Adapter (Interacts with credit rating check system.) Send Notification Adapter ( Interacts with notification system ) FTP adapter (For intracting with FTp server to store customers information) Conclusion This is my understanding about hexagonal architecture. If you want to get more information on the topic, read Alistair Cockburn’s original article on the subject I hope this article will help you understand idea of Hexagonal Architecture and who they are comes together I’ll be glad for any feedback!

Hexagonal Architecture: Use Case Part II

A guided tour of our service template Photo by on … Came up when I searched for ‘hexagon’. But surely more sides is better, so we’ll let it pass. Ilnur Kalimullin Unsplash It happened the other day that a team I was working with felt the right answer to a question about which tech stack to use for a microservice was ‘Kotlin with Ktor using a ports and adapters architecture, building with as a multi-module Gradle project with the Kotlin Gradle DSL. Plus Guice for dependency injection.’ Only no-one on the internet seems to have implemented a microservice with that particular combination of structure and technology before. Or at least, no-one has talked about it. Each individual thing I mentioned, yes, there is information available — but putting the pieces together was a challenge. some So… are you listening web-spiders? Are you paying attention, page-rank? I said: Kotlin with Ktor Ports and Adapters Gradle multi module project with the Kotlin DSL Guice Why these things? : Because Kotlin is . Everyone . Kotlin awesome says so : Because if you need a on top of a in order to simplify your , something has probably gone wrong somewhere. Ktor framework framework framework P&A, also known as ‘hexagonal architecture’, is an tool for producing testable, . I struggled for a long time to articulate why I found it so much more powerful than an ‘n-tiered architecture with DI’. I think it boils down to cementing the concept of ‘inside’ vs. ‘outside’. Business logic and the domain model goes ‘inside’. is outside. I have no doubt with sufficient discipline you can accomplish the same thing with other architectural styles. But applying P&A gives you some strong conventions to help guide your thoughts. Ports and Adapters: incredibly powerful mental clean architecture Everything else Curiosity, mostly. I’ve used Maven extensively in the past and made my peace with it. But I’ve heard good things about Gradle and I was curious to use it ‘in anger’, as it were. Gradle: Because Groovy and I have parted ways. Also, curiosity. Also, masochism. The Gradle Kotlin DSL: Ahah. Well, now… I find the reaction to adding modules to a project, especially a relatively trivial microservice, quite mixed. Everything from, “It’s fine — the structure helps”, to “GET YOUR FILTHY STINKING MODULES AWAY FROM MY CODE.” (Well, the actual words were ‘What? No!’ — but my super-power is hearing what isn’t said.) It’s a surprisingly divisive issue! The reason I choose multi-modules is to manage dependencies. It helps keep you honest, helps you enforce your own rules. For example, ‘ ’ or ‘ ’. Sure, it adds some complexity and might feel unjustified for a small service. But if you’re producing multiple services you only take that complexity hit once — then you have a simple template to follow for all the rest. And, be honest, how often do your ‘micro’ services actually stay micro? Multi-modules: Domain shouldn’t know anything about JSON because it’s a transport layer concern Controller can’t talk directly to the database : Because it’s not Spring, we’re used to using Guice with Play, and there was some assistance on the ktor website. Guice The code is the truth. You can find our ‘hello world’ service template here: https://github.com/sgerber-hyperanna/ktor-hexagonal-multi-module-template Let’s do a quick walk-through of the different modules though, their dependencies and any challenges involved setting them up. Module Layout Module diagram auto-generated by IntelliJ Our ports and adapters implementation has four modules: App, Domain, Ports, Adapters. Both ‘Domain’ and ‘Adapters’ depend on ‘Ports’. ‘Domain’ and ‘Adapters’ cannot see each other. ‘App’ can see all the modules. What Goes Where? Domain The centre of the hexagon. Contains core business logic and the domain model. Importantly, contains no references to transport concerns like JSON, specific persistence technologies or Yes, time. is an anti-pattern at the domain layer because it complicates testing and creates a degree of temporal coupling. Pass in dates and timestamps from the adapter layer if you need them. time. DateTime.now() Adapters Everything outside the hexagon. Nothing related to business logic. Will contain things like JSON transformers, REST end-points, message handlers, event publishers, database repositories, scheduled events, and so forth Ports The ports module contains interfaces and DTOs (which will be Kotlin data classes in our case). It should have no actual logic and therefore not really need any tests. There are varying ways people arrange and name their ports, but the structure I like is to subdivide into two categories: Required and Provided. ports are required by the ‘domain’ for the application to function. Hence they are i_mplemented by the adapter module_. Repositories, event publishers and API clients might be accessed through ‘required’ ports. Required ports are provided by ‘domain’ for use by the adapter layer. Hence they are . Service classes called from your controllers, event handlers and scheduled tasks are the most typical examples of ‘provided’ ports. Provided implemented by the domain module App The ‘app’ module binds everything together and configures the framework being used to run the service. In this case it loads Guice modules and configures Ktor. The guided tour: Domain logic There’s not much in our toy domain. Just a that implements our interface (a ‘provided’ port) and is injected with a (a ‘required’ port). SimpleGreeter Greeter GreetingsRepository Testing this is easy, we can just mock the repository. In general when testing ‘domain’ we want to mock out the ‘adapter’ implementations. As an aside, I prefer using kotlintest assertions with JUnit5 and Mockito-kotlin. Adapter layer The most interesting thing about the adapter layer is how to ‘inject’ domain services into Ktor routes. The first step is to assume we can inject our Ktor along with any ‘provided’ services and write a simple class that sets up the routes. Application You can see above that once we inject the application class you can initiate the ktor routing DSL as per normal. We can also have multiple classes setting up routing. Effectively this lets our ‘route’ classes play the same role a Controller would in, say, a SpringMVC application. The next step is to setup the rest of ktor, such as exception handling and content transformers. We do this in ApplicationConfig.kt The final step is to create a Guice module that binds the application for injecting, then feeds it into the route and config classes. The key here is to use when binding the configuration and the routes. As the Javadoc says, “ asEagerSingleton Useful for application initialization logic” Writing adapter tests This is where things get interesting. When we write ‘domain’ tests we don’t need to worry about much plumbing or wiring. Adapter tests, however, are where you probably want to write some integration tests. Given our hexagonal architecture, we’re looking for a way to start a test Ktor application but wire in mocks for all the domain services. In our toy example we don’t have a ‘real’ database, so we can write integration-like tests to demonstrate the concepts without actually needing to integrate Docker or similar to provide external dependencies. Step 1: Create mocks for our core services There’s only one in our template, but it illustrates the point. Step 2: Create a Guice injector On line 3 above we inject the Adapter Module. This means we can test the actual-factual routes with confidence. We also inject our mocked domain services. real The here lets us inject our test application into the adapter module. MainModule Also note that the function on line 2 above is an extension function off Application. module Step 3: Setup/TearDown methods to create a test application Line 6 above we use the Ktor testkit to create a test environment. Line 10 wires up the test application with our routes and mocks by calling the extension method from Step 2. Line 12 injects the test class itself with anything in the Guice context so that we can wire mocks up into our tests, as we shall see in the next step. Step 4: Write a test In this step we subclass our test base to call a ktor route. Worth calling out here is that on lines 4/5 we inject the mocked domain service into our test class. Line 17 demonstrates a simple way to test a ktor route. This adapter integration test gives us confidence that: The route works The service was called The HTTP call returned the expected status and content (so, for example, we could check JSON marshaling and unmarshaling was working) Wiring up the application Our ‘app’ module can see both ‘domain’ and ‘adapters’ and is responsible for wiring everything up and launching the application. There’s not much in here except for the actual main module and an entry point. However — if you feel compelled to write a true end-to-end integration test against a real running service — this is the module to do it in. I’m not sure if you should, though. If you trust the framework, and trust that your ‘layer crossing tests’ give you sufficient coverage that the adapters are calling the domain the right way and vice-versa, you can get away without needing to write any of these tests. On the other hand, one or two ‘sanity tests’ that execute as part of an integration test phase probably wouldn’t hurt too much. You can find an in the GitHub repository, but there is not much to learn from reviewing a code-snippet here. It is very similar in appearance to the Adapter test. Just less setup, because everything is real. example And all the rest … Well that’s end of our tour! There is a little more to see if you care to explore the repository. You can see examples of how we managed to hack together a multi-module project with the Kotlin DSL. You can also see how we integrated some simple JWT authentication into our end-points. Now I realize that the amount of setup code and Gradle configuration drastically dwarfs the amount of actual application code in this toy application. This may understandably lead you feel that it’s all more hassle than it’s worth. I take your point, and I agree. But my counter-argument is that ports and adapters as an architectural style, as a , really didn’t click for me until I’d built a couple of services with it and seen how cleanly, how beautifully, everything fell together. Please do give it a go, even if you are not feeling totally convinced. discipline If you happen to be using Kotlin and ktor, I hope this tutorial is of direct benefit! Most of this was figured out from scratch with little detailed knowledge of ktor or Kotlin. There might be better ways to achieve the same goals! Discussions and pull-requests against the service template in GitHub are welcome. If you are not currently using Kotlin, I hope it at least gives some insight into how you might organize your chosen technology stack into a ports and adapters structure.

Hexagonal Architecture with Kotlin, Ktor and Guice

Decoupling Technical Code from Business Logic with Hexagonal Architecture

MIAMI, Florida, November 13th, 2024/Chainwire/--Valhalla, Floki's PlayToEarn Massively Multiplayer Online Role-Playing Game (MMORPG) blockchain game is proud to announce a partnership in the United Arab Emirates (UAE). On Nov. 13, Valhalla unveiled a partnership with Dubai's Mall of the Emirates, marking a milestone in its global outreach efforts. The partnership will see Valhalla’s branding prominently displayed across 93 screens in the mall for a four-week campaign running from November 15 to December 12. Mall of the Emirates, located in the heart of Dubai, is one of the world’s most prestigious shopping destinations. Since opening in 2005, it has become an iconic landmark, attracting millions of visitors each year. The mall sees daily traffic of approximately 111,500 people, making it a prime venue for Valhalla’s campaign to reach a diverse and international audience. The mall’s strategic location on Sheikh Zayed Road, a prime area in Dubai, combined with its diverse visitor base, offers Valhalla an opportunity to engage both local and international audiences. Spanning an area of 255,489 square meters, the multi-level mall boasts over 630 retail outlets, 80 luxury stores, and 250 flagship stores. It also features some of Dubai’s most popular attractions, including the indoor ski resort Ski Dubai, the Magic Planet entertainment center, and VOX Cinemas. The mall’s dining options, with over 100 restaurants and cafés, further enhance its appeal as a top destination for both residents and tourists. The Campaign’s Goal Valhalla is ramping up its presence in the UAE, a key market for crypto adoption. Despite its smaller population, the UAE ranks as the third-largest crypto economy in the MENA region, with $34 billion in crypto transactions recorded between July 2023 and June 2024. This represents an impressive 42% year-on-year growth, far outpacing the MENA average of 11.73%, according to Chainalysis. Dubai’s rapid evolution into a crypto hub has been fueled by initiatives like the Dubai International Financial Centre (DIFC) and Virtual Asset Regulatory Authority (VARA), which offer crypto-friendly regulatory frameworks.This has drawn major players and startups, solidifying Dubai’s status as a global crypto leader. Valhalla’s campaign at Mall of the Emirates aligns perfectly with this momentum. By showcasing its brand in one of Dubai’s busiest and most iconic locations, Floki aims to boost awareness and adoption of its ecosystem. This campaign follows Floki’s recent four-week marketing initiative at WAFI Mall in Dubai, running from November 8 to December 5, where its branding appears across 18 digital screens. Together, these efforts are part of Floki’s larger strategy to dominate the Dubai crypto scene. About Valhalla Valhalla is a blockchain-based MMORPG inspired by Norse mythology, offering players the chance to discover, tame, and battle with creatures called Veras. The game features a player-driven economy and a hexagonal battlefield designed for dynamic combat. Users can learn more at Valhalla.game. About Floki Floki is the people’s cryptocurrency and utility token of the Floki Ecosystem. Focused on utility, community, philanthropy, and strategic marketing, Floki is working toward becoming the world’s most recognized and used cryptocurrency. With over 490,000 holders globally, Floki has already established a strong brand presence. Users can learn more at floki.com. Website | Youtube | Telegram | Instagram | Tik Tok | Discord | Facebook | Reddit | Twitch | Valhalla Contact Vidal Pedro Floki Marketing@floki.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here MIAMI, Florida, November 13th, 2024/Chainwire/--Valhalla, Floki's PlayToEarn Massively Multiplayer Online Role-Playing Game (MMORPG) blockchain game is proud to announce a partnership in the United Arab Emirates (UAE). On Nov. 13, Valhalla unveiled a partnership with Dubai's Mall of the Emirates, marking a milestone in its global outreach efforts. The partnership will see Valhalla’s branding prominently displayed across 93 screens in the mall for a four-week campaign running from November 15 to December 12. Mall of the Emirates, located in the heart of Dubai, is one of the world’s most prestigious shopping destinations. Since opening in 2005, it has become an iconic landmark, attracting millions of visitors each year. The mall sees daily traffic of approximately 111,500 people, making it a prime venue for Valhalla’s campaign to reach a diverse and international audience. The mall’s strategic location on Sheikh Zayed Road, a prime area in Dubai, combined with its diverse visitor base, offers Valhalla an opportunity to engage both local and international audiences. Spanning an area of 255,489 square meters, the multi-level mall boasts over 630 retail outlets, 80 luxury stores, and 250 flagship stores. It also features some of Dubai’s most popular attractions, including the indoor ski resort Ski Dubai, the Magic Planet entertainment center, and VOX Cinemas. The mall’s dining options, with over 100 restaurants and cafés, further enhance its appeal as a top destination for both residents and tourists. The Campaign’s Goal Valhalla is ramping up its presence in the UAE, a key market for crypto adoption. Despite its smaller population, the UAE ranks as the third-largest crypto economy in the MENA region, with $34 billion in crypto transactions recorded between July 2023 and June 2024. This represents an impressive 42% year-on-year growth, far outpacing the MENA average of 11.73%, according to Chainalysis . according to Chainalysis according to Chainalysis Dubai’s rapid evolution into a crypto hub has been fueled by initiatives like the Dubai International Financial Centre (DIFC) and Virtual Asset Regulatory Authority (VARA), which offer crypto-friendly regulatory frameworks.This has drawn major players and startups, solidifying Dubai’s status as a global crypto leader. Valhalla’s campaign at Mall of the Emirates aligns perfectly with this momentum. By showcasing its brand in one of Dubai’s busiest and most iconic locations, Floki aims to boost awareness and adoption of its ecosystem. This campaign follows Floki’s recent four-week marketing initiative at WAFI Mall in Dubai, running from November 8 to December 5, where its branding appears across 18 digital screens. Together, these efforts are part of Floki’s larger strategy to dominate the Dubai crypto scene. About Valhalla Valhalla is a blockchain-based MMORPG inspired by Norse mythology, offering players the chance to discover, tame, and battle with creatures called Veras. The game features a player-driven economy and a hexagonal battlefield designed for dynamic combat. Users can learn more at Valhalla.game . Valhalla Valhalla Valhalla.game Valhalla.game About Floki Floki is the people’s cryptocurrency and utility token of the Floki Ecosystem. Focused on utility, community, philanthropy, and strategic marketing, Floki is working toward becoming the world’s most recognized and used cryptocurrency. With over 490,000 holders globally, Floki has already established a strong brand presence. Users can learn more at floki.com . Floki Floki floki.com floki.com Website | Youtube | Telegram | Instagram | Tik Tok | Discord | Facebook | Reddit | Twitch | Valhalla Website Website Youtube Youtube Telegram Telegram Instagram Instagram Tik Tok Tik Tok Discord Discord Facebook Facebook Reddit Reddit Twitch Twitch Valhalla Valhalla Contact Vidal Pedro Floki Marketing@floki.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here here here

Floki’s Valhalla Partners With Dubai’s Mall Of The Emirates For Landmark Campaign

Floki-nin Valhalla, Landmark Kampaniyası üçün Dubayın Mall Of The Emirates ilə ortaqdır

ল্যান্ডমার্ক ক্যাম্পেইনের জন্য দুবাইয়ের মল অফ এমিরেটসের সাথে ফ্লোকির ভালহাল্লা অংশীদার

Floki's Valhalla spolupracuje s dubajským nákupním centrem Mall Of The Emirates for Landmark Campaign

Floki’s Valhalla se asocia con el centro comercial Mall of the Emirates de Dubái para una campaña emblemática

フロキのヴァルハラがドバイのエミレーツ・モールと提携して画期的なキャンペーンを展開

ल्यान्डमार्क अभियानको लागि दुबईको मल्ल अफ एमिरेट्ससँग फ्लोकीको भल्हल्ला साझेदारहरू

د فلوکي والهاله د تاریخي کمپاین لپاره د دوبۍ د اماراتو مال سره ملګرتیا کوي

Valhalla da Floki faz parceria com o Mall of the Emirates de Dubai para uma campanha histórica

Floki's Valhalla bashkëpunon me fushatën e Dubait Mall Of The Emirates për të shënuar

Floki's Valhalla бо Mall Of Emirates дар Дубай барои маъракаи муҳим шарикӣ мекунад

Floki’s Valhalla співпрацює з Dubai’s Mall of the Emirates для знакової кампанії

UFloki's Valhalla Partners kunye neDubai Mall ye-Emirates yePhulo eliLandmark

MIAMI, Florida, October 25th, 2024/Chainwire/--Valhalla Floki’s PlayToEarn Massively Multiplayer Online Role-Playing Game (MMORPG) blockchain game, has teamed up with the Hong Kong International Cricket Sixes as its official partner, marking the much-anticipated return of the tournament after a seven-year break. From November 1 to November 3, top international teams will face off in this fast-paced cricket format at the Tin Kwong Road Recreation Ground. The Cricket Sixes has been a celebrated event since its debut in 1992, with legendary players like Sachin Tendulkar, MS Dhoni, Shane Warne, and Sanath Jayasuriya gracing the field over the years. Valhalla’s partnership with the Sixes reflects the synergy between competitive sports and the blockchain gaming world. “We are thrilled to be part of the Hong Kong International Cricket Sixes. The excitement and energy of this iconic event resonate with our own commitment to innovation and community in gaming,” said Mr. Brown Whale, Valhalla's lead. “This collaboration allows us to engage with cricket fans and show how PlayToEarn gaming can elevate both entertainment and the spirit of competition.” The matches will be broadcast across multiple regions by Star Sports Network, and in India, viewers can catch the action on Fancode, one of the country’s largest sports OTT platforms. On the ground, key branding assets will include ground perimeter boards, mid wicket logo mats, and the presentation backdrop, ensuring strong visibility for both Valhalla and the Sixes event. This year’s tournament will feature 12 teams divided into four groups. In Group C, India, led by stars like Robin Uthappa and Kedar Jadhav, will face off against Pakistan and the UAE. Group A includes South Africa, New Zealand, and host nation Hong Kong. Group B brings together Australia, England, and Nepal, while Sri Lanka, Bangladesh, and Oman make up Group D. The top two teams from each group will progress to the quarterfinals, with 29 matches set to take place over three action-packed days. About Hong Kong Sixes The Hong Kong Cricket Sixes is a six-a-side international cricket tournament held at the Kwong Road recreational ground from 1st to 3rd Nov. The 2024 edition will be conducted after a 7 year gap and 12 of the best cricketing nations will battle it out for top honors. Uses can learn more at www.hkcricket.org About Valhalla Valhalla is a blockchain-based MMORPG inspired by Norse mythology, offering players the chance to discover, tame, and battle with creatures called Veras. The game features a player-driven economy and a hexagonal battlefield designed for dynamic combat. Users can learn more at Valhalla.game. Website | YouTube | Telegram | Instagram | TikTok | Discord | Facebook | Reddit | Twitch Contact Community Relations Officer Pedro Vidal FLOKI marketing@floki.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here MIAMI, Florida, October 25th, 2024/Chainwire/--Valhalla Floki’s PlayToEarn Massively Multiplayer Online Role-Playing Game (MMORPG) blockchain game, has teamed up with the Hong Kong International Cricket Sixes as its official partner, marking the much-anticipated return of the tournament after a seven-year break. From November 1 to November 3, top international teams will face off in this fast-paced cricket format at the Tin Kwong Road Recreation Ground. The Cricket Sixes has been a celebrated event since its debut in 1992, with legendary players like Sachin Tendulkar, MS Dhoni, Shane Warne, and Sanath Jayasuriya gracing the field over the years. Valhalla’s partnership with the Sixes reflects the synergy between competitive sports and the blockchain gaming world. “We are thrilled to be part of the Hong Kong International Cricket Sixes. The excitement and energy of this iconic event resonate with our own commitment to innovation and community in gaming,” said Mr. Brown Whale, Valhalla's lead. “We are thrilled to be part of the Hong Kong International Cricket Sixes. The excitement and energy of this iconic event resonate with our own commitment to innovation and community in gaming,” said Mr. Brown Whale, Valhalla's lead. “This collaboration allows us to engage with cricket fans and show how PlayToEarn gaming can elevate both entertainment and the spirit of competition.” “This collaboration allows us to engage with cricket fans and show how PlayToEarn gaming can elevate both entertainment and the spirit of competition.” The matches will be broadcast across multiple regions by Star Sports Network, and in India, viewers can catch the action on Fancode, one of the country’s largest sports OTT platforms. On the ground, key branding assets will include ground perimeter boards, mid wicket logo mats, and the presentation backdrop, ensuring strong visibility for both Valhalla and the Sixes event. This year’s tournament will feature 12 teams divided into four groups. In Group C, India, led by stars like Robin Uthappa and Kedar Jadhav, will face off against Pakistan and the UAE. Group A includes South Africa, New Zealand, and host nation Hong Kong. Group B brings together Australia, England, and Nepal, while Sri Lanka, Bangladesh, and Oman make up Group D. The top two teams from each group will progress to the quarterfinals, with 29 matches set to take place over three action-packed days. About Hong Kong Sixes The Hong Kong Cricket Sixes is a six-a-side international cricket tournament held at the Kwong Road recreational ground from 1st to 3rd Nov. The 2024 edition will be conducted after a 7 year gap and 12 of the best cricketing nations will battle it out for top honors. Uses can learn more at www.hkcricket.org www.hkcricket.org www.hkcricket.org About Valhalla Valhalla is a blockchain-based MMORPG inspired by Norse mythology, offering players the chance to discover, tame, and battle with creatures called Veras. The game features a player-driven economy and a hexagonal battlefield designed for dynamic combat. Users can learn more at Valhalla.game . Valhalla Valhalla Valhalla.game Valhalla.game Website | YouTube | Telegram | Instagram | TikTok | Discord | Facebook | Reddit | Twitch Website Website YouTube YouTube Telegram Telegram Instagram Instagram TikTok TikTok Discord Discord Facebook Facebook Reddit Reddit Twitch Twitch Contact Community Relations Officer Pedro Vidal FLOKI marketing@floki.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here here

Valhalla Partners With Hong Kong International Cricket Sixes For a Thrilling Comeback

Η Valhalla συνεργάζεται με το Hong Kong International Cricket Sixes για μια συναρπαστική επιστροφή

Valhalla se asocia con Hong Kong International Cricket Sixes para un regreso emocionante

Valhalla s'associe à Hong Kong International Cricket Sixes pour un retour palpitant

वल्लाह ने रोमांचक वापसी के लिए हांगकांग इंटरनेशनल क्रिकेट सिक्सेस के साथ साझेदारी की

Valhalla se udružila s Hong Kong International Cricket Sixes za uzbudljiv povratak

ヴァルハラが香港国際クリケットシックスと提携し、スリリングなカムバックを果たす

Valhalla Bekerjasama Dengan Hong Kong International Cricket Sixes Untuk Kemunculan Kembali yang mendebarkan

Valhalla o Dirišana Le Hong Kong International Cricket Sixes Bakeng sa go Boa mo go Kgahlišago

Abafatanyabikorwa ba Valhalla hamwe na Hong Kong mpuzamahanga ya Cricket itandatu yo kugaruka gushimishije

Valhalla spolupracuje s Hongkongskými medzinárodnými kriketovými šestkami pre vzrušujúci návrat

I-Valhalla isebenzisana nabadlali beQakamba baMazwe ngaMazwe baseHong Kong ukuze bafumane iMbuyiselo echulumancisayo

I-Valhalla Isebenzisana Nabadlali Abayisithupha Bekhilikithi Yamazwe Ngamazwe base-Hong Kong Ukuze Kubuyelwe Okujabulisayo

**MIAMI, Florida, October 17th, 2024/GamingWire/--**Valhalla, Floki’s revolutionary blockchain-based Massively Multiplayer Online Role-Playing Game (MMORPG),has proudly announced a new partnership with Hafthor Júlíus Björnsson, the world-renowned strongman and actor famous for his role as "The Mountain" in Game of Thrones. Hafthor is joining Valhalla as its official ambassador, marking the beginning of an exciting collaboration. This long-term partnership will bring Hafthor, the world’s strongest man and a multiple-time winner of prestigious titles such as the World’s Strongest Man and Arnold Strongman Classic, into the heart of the Valhalla universe. His unmatched strength and strategic prowess will enhance the Valhalla game experience for players worldwide. Hafthor will play a vital role in Valhalla, guiding players as they strengthen their bonds with their Veras, develop new combat strategies, and engage in dynamic in-game activities. His influence will be woven into The Tempest Forge, a monumental feature constructed during the Unleash the Thunder community event. Future developments will include a brand-new game mode where Hafthor and The Tempest Forge challenge players to face waves of Veras, helping them refine their battle skills and tactics to push their limits. In addition to his in-game presence, Hafthor will remain actively engaged with the Valhalla community, creating content and sharing exclusive updates. He will feature regularly on social media platforms and host monthly Twitch streams, where players can join him as he plays his own in-game character. This partnership will bring a new level of excitement to the Valhalla community, as players prepare to explore the game under the guidance of one of the strongest men in history. About Floki Floki is the people’s cryptocurrency and utility token of the Floki Ecosystem. Focused on utility, community, philanthropy, and strategic marketing, Floki is working toward becoming the world’s most recognized and used cryptocurrency. With over 490,000 holders globally, Floki has already established a strong brand presence. Learn more at floki.com. About Valhalla Valhalla is a blockchain-based MMORPG inspired by Norse mythology, offering players the chance to discover, tame, and battle with creatures called Veras. The game features a player-driven economy and a hexagonal battlefield designed for dynamic combat. Learn more at Valhalla.game. About Hafthor Björnsson Hafthor Júlíus Björnsson is an Icelandic strongman, actor, and world record holder, most famously known for his role as “The Mountain” in Game of Thrones. Hafthor has won multiple strongman competitions, including the World’s Strongest Man and Europe’s Strongest Man. His legacy as one of the strongest men in history continues to inspire audiences worldwide. Learn more about Hafthor at thorsapparel.com. Contact Community Relations Officer Pedro Vidal Floki marketing@floki.com This story was distributed as a release by Gamingwire under HackerNoon’s Business Blogging Program. Learn more about the program here. **MIAMI, Florida, October 17th, 2024/GamingWire/--**Valhalla, Floki’s revolutionary blockchain-based Massively Multiplayer Online Role-Playing Game (MMORPG),has proudly announced a new partnership with Hafthor Júlíus Björnsson, the world-renowned strongman and actor famous for his role as "The Mountain" in Game of Thrones. Hafthor is joining Valhalla as its official ambassador, marking the beginning of an exciting collaboration. This long-term partnership will bring Hafthor, the world’s strongest man and a multiple-time winner of prestigious titles such as the World’s Strongest Man and Arnold Strongman Classic, into the heart of the Valhalla universe. His unmatched strength and strategic prowess will enhance the Valhalla game experience for players worldwide. Hafthor will play a vital role in Valhalla, guiding players as they strengthen their bonds with their Veras, develop new combat strategies, and engage in dynamic in-game activities. His influence will be woven into The Tempest Forge, a monumental feature constructed during the Unleash the Thunder community event. Future developments will include a brand-new game mode where Hafthor and The Tempest Forge challenge players to face waves of Veras, helping them refine their battle skills and tactics to push their limits. In addition to his in-game presence, Hafthor will remain actively engaged with the Valhalla community, creating content and sharing exclusive updates. He will feature regularly on social media platforms and host monthly Twitch streams, where players can join him as he plays his own in-game character. This partnership will bring a new level of excitement to the Valhalla community, as players prepare to explore the game under the guidance of one of the strongest men in history. About Floki Floki is the people’s cryptocurrency and utility token of the Floki Ecosystem. Focused on utility, community, philanthropy, and strategic marketing, Floki is working toward becoming the world’s most recognized and used cryptocurrency. With over 490,000 holders globally, Floki has already established a strong brand presence. Learn more at floki.com . floki.com floki.com About Valhalla Valhalla is a blockchain-based MMORPG inspired by Norse mythology, offering players the chance to discover, tame, and battle with creatures called Veras. The game features a player-driven economy and a hexagonal battlefield designed for dynamic combat. Learn more at Valhalla.game . Valhalla.game Valhalla.game About Hafthor Björnsson Hafthor Júlíus Björnsson is an Icelandic strongman, actor, and world record holder, most famously known for his role as “The Mountain” in Game of Thrones. Hafthor has won multiple strongman competitions, including the World’s Strongest Man and Europe’s Strongest Man. His legacy as one of the strongest men in history continues to inspire audiences worldwide. Learn more about Hafthor at thorsapparel.com . thorsapparel.com thorsapparel.com Contact Community Relations Officer Pedro Vidal Floki marketing@floki.com This story was distributed as a release by Gamingwire under HackerNoon’s Business Blogging Program. Learn more about the program here. This story was distributed as a release by Gamingwire under HackerNoon’s Business Blogging Program. Learn more about the program here . here here

FLOKI’s Valhalla Welcomes Hafthor Björnsson From Game Of Thrones As Official Ambassador

Valhalla z FLOKI vítá Hafthora Björnssona z Game of Thrones jako oficiálního velvyslance

Valhalla de FLOKI da la bienvenida a Hafthor Björnsson de Juego de Tronos como embajador oficial

FLOKI-ren Valhalla-k Game Of Thrones-eko Hafthor Björnsson-ek ongietorria ematen dio enbaxadore ofizial gisa

FLOKIjeva Valhalla pozdravlja Hafthora Björnssona iz Igre prijestolja kao službenog veleposlanika

FLOKIのヴァルハラがゲーム・オブ・スローンズのハフソー・ビョルンソンを公式アンバサダーとして迎える

FLOKI’s Valhalla Ayambi Hafthor Björnsson Na Game Of Thrones Lokola Ambassadeur Officiel

Valhalla FLOKI wita Hafthora Björnssona z Gry o Tron jako oficjalnego ambasadora

FLOKI හි Valhalla නිල තානාපති ලෙස Game Of Thrones වෙතින් Hafthor Björnsson පිළිගනී

Валҳаллаи ФЛОКИ Ҳафтор Бёрнссонро аз бозии тахтҳо ба ҳайси сафири расмӣ истиқбол кард

FLOKI’s Valhalla ንሃፍቶር ቢዮርንሶን ካብ Game Of Thrones ከም ወግዓዊ ኣምባሳደር ተቐቢላቶ

FLOKI’s Valhalla вітає Хафтора Бйорнссона з «Гри престолів» як офіційного посла

FLOKIning Valhalla rasmiy elchi sifatida "Taxtlar o'yini"dan Hafthor Byornssonni kutib oldi

Stories, News & Mentions about HEXIGONAI

Hexigonai’s Stories on HackerNoon