Posts tagged with “architecture”

Remaining ports are much simpler in their scope, and in the fact they do not manage dynamic subscriptions. We will review them quickly for completeness.

In the “modules and components” post, we defined the trading port as a gateway to exchanges, managing a trading account, placing and canceling orders.

So far, we have been talking about market events, orders and strategies, as abstract concepts, leaving details to a later point. Now, to design the core of the strategy engine, we need the full picture.

We used most of the allocated design time, and our architecture is falling into place. Spending more time on upfront design will yield diminishing returns at this point. Here is a quick post index.

We detail critical parts of the architecture: relationships between main components, strategy life-cycle and integration examples for both testing and production.

Event-driven, hexagonal, micro-services… we can quickly trim down the options to a few candidates. We will then explore, evaluate and select one of them.

We understand the problem and can start building our high-level architecture. We will start with mapping the requirements to project elements.

Constraints, functional requirements, quality attributes. All of those are known as architecturally significant requirements. Characterizing those is the final step in our initial “understand phase”.

We will start our job with identifying all stakeholders we can. Then, depending on how close to the project they are, we will get to know them and find out their goals.

A new project with no legacy to accommodate may either be a clean slate or a blank page, depending on how one looks at it. Before we start filling it, we need to define our strategy.