Architects use the architecture quantum measure as a way to think about deployment, coupling, where data should reside, and communication styles within architectures. (link)
Architects must remember that the analysis to yield architecture characteristics represents only a small part of the overall effort to design and implement an application—a lot of design work happens past this phase! During this part of architecture definition, architects look for requirements with structural impact not already covered by the domain. (link)
In modern systems, architects define architecture characteristics at the quantum level rather than system level. (link)
The bounded context concept recognizes that each entity works best within a localized context. Thus, instead of creating a unified Customer class across the entire organization, each problem domain can create its own and reconcile differences at integration points. (link)
Before DDD, developers sought holistic reuse across common entities within the organization. Yet creating common shared artifacts causes a host of problems, such as coupling, more difficult coordination, and increased complexity (link)
Architecture quantum An independently deployable artifact with high functional cohesion and synchronous connascence (link)
We could eliminate customizability as an architecture characteristic and plan to implement that behavior as part of application design. (link)
A useful exercise once the team has made a first pass at identifying the architecture characteristics is to try to determine the least important one—if you must eliminate one, which would it be (link)
Architects must remember: there is no best design in architecture, only a least worst collection of trade-offs. (link)
Architects shouldn’t stress too much about discovering the exactly correct set of architecture characteristics—developers can implement functionality in a variety of ways (link)
The architecture implies some structural component, whereas design resides within the architecture. (link)
his design element isn’t critical to the success of the application though. It is important to note that there are no correct answers in choosing architecture characteristics, only incorrect ones (or, as Mark notes in one of his well-known quotes):
There are no wrong answers in architecture, only expensive ones. (link)
Often, elastic systems also need scalability: the ability to handle bursts and high numbers of concurrent users. (link)
A common anti-pattern in architecture entails trying to design a generic architecture, one that supports all the architecture characteristics. (link)
Leveraging automation by creating simple command-line tools and analyzers to help the development team with their day-to-day tasks is another great way to maintain hands-on coding skills while making the development team more effective (link)
The second reason is that by writing production-quality proof-of-concept code, the architect gets practice writing quality, well-structured code rather than continually developing bad coding practices. (link)
The first way is to do frequent proof-of-concepts or POCs (link)
The point here is that everything in software architecture has a trade-off: an advantage and disadvantage. Thinking like an architect is analyzing these trade-offs, then asking “which is more important: extensibility or security?” The decision between different solutions will always depend on the business drivers, environment, and a host of other factors. (link)
n the queue option in Figure 2-9, each consumer can have its own contract specific to the data it needs (link)
In other words, it is very easy to wiretap into a topic, but not a queue (link)
Programmers know the benefits of everything and the trade-offs of nothing. Architects need to understand both (link)
There are no right or wrong answers in architecture—only trade-offs. (link)
Unlike a developer, who must have a significant amount of technical depth to perform their job, a software architect must have a significant amount of technical breadth to think like an architect and see things with an architecture point of view (link)
It’s really through collaboration with the development team that the architect is able to gain the respect of the team and form better solutions. The more developers respect an architect, the easier it will be for the architect to negotiate with those developers. (link)
If a developer disagrees with a decision, have them arrive at the solution on their own. (link)
Notice here the architect is providing the justification for the demand that all requests need to go through the business layer of the application. (link)
When convincing developers to adopt an architecture decision or to do a specific task, provide a justification rather than “dictating from on high.” (link)
Always remember that demonstration defeats discussion. (link)
Another inherent difference between the broker and mediator topology is how the processing events differ in terms of their meaning and how they are used. In the broker topology example in the previous section, the processing events were published as events that had occurred in the system (such as order-created, payment-applied, and email-sent). The event processors took some action, and other event processors react to that action. However, in the mediator topology, processing occurrences such as place-order, send-email, and fulfill-order are commands (things that need to happen) as opposed to events (things that have already happened). Also, in the mediator topology, a command must be processed, whereas an event can be ignored in the broker topology. (link)
Because the mediator controls the workflow, it can maintain event state and manage error handling, recoverability, and restart capabilities. (link)
he simple mediator can then interrogate the classification of the event, and based on that classification, handle the event itself or forward it to another, more complex, event mediator (link)
It is important to know the types of events that will be processed through the mediator in order to make the correct choice for the implementation of the event mediator. Choosing Apache Camel for complex and long-running events involving human interaction would be extremely difficult to write and maintain. By the same token, using a BPM engine for simple event flows would take months of wasted effort when the same thing could be accomplished in Apache Camel in a matter of days. (link)
Central to this topology is an event mediator, which manages and controls the workflow for initiating events that require the coordination of multiple event processors. (link)
The topics provide the back pressure point if an event processor comes down or slows down due to some environment issue. (link)
Vikram: [Probably means that messsages are queued up]
The event broker component is usually federated (meaning multiple domain-based clustered instances), where each federated broker contains all of the event channels used within the event flow for that particular domain. (link)
Vikram: [This probably means that a queue manager has all of the queues for a particular domain]
The broker topology differs from the mediator topology in that there is no central event mediator. (link)
An event-based model, on the other hand, reacts to a particular situation and takes action based on that event. An example of an event-based model is submitting a bid for a particular item within an online auction. (link)
A good example of the request-based model is a request from a customer to retrieve their order history for the past six months. Retrieving order history information is a data-driven, deterministic request made to the system for data within a specific context, not an event happening that the system must react to. (link)
However, the fundamental decision rests on how many quanta the architecture discovers during the design process. If the system can manage with a single quantum (in other words, one set of architecture characteristics), then a monolith architecture offers many advantages. On the other hand, differing architecture characteristics for components, as illustrated in the GGG component analysis, requires a distributed architecture to accommodate differing architecture characteristics (link)
Rather, try to objectively assess the trade-offs between different design decisions, and choose the one that has the least worst set of trade-offs. (link)
As an architect, don’t obsess over finding the one true design, because many will suffice (and less likely overengineered (link)
The entity trap anti-pattern arises when an architect incorrectly identifies the database relationships as workflows in the application, a correspondence that rarely manifests in the real world (link)
No accepted “correct” way exists to design components (link)
This mapping doesn’t have to be exact—the architect is attempting to find a good coarse-grained substrate to allow further design and refinement by architects, tech leads, and/or developers (link)
Outside that, an architect has the freedom to make up whatever components they want, then map domain functionality to them to see where behavior should reside (link)
In a modular monolith, the architect partitions the architecture around domains or workflows rather than technical capabilities (link)
The other is an architecture style popularized by Simon Brown called a modular monolith, a single deployment unit associated with a database and partitioned around domains rather than technical capabilities (link)
An architect must identify components as one of the first tasks on a new project (link)
Virtually all the details we cover in this book exist independently from whatever software development process teams use: architecture is independent from the development process (link)
However, architects typically think in terms of components, the physical manifestation of a module. (link)
For example, architects seriously rethought the implications of code reuse after building architectures that featured it and then realizing the negative trade-offs. (link)
However, they differ because interoperability implies ease of integration with other systems, which in turn implies published, documented APIs. Compatibility, on the other hand, is more concerned with industry and domain standards. (link)
Support for each architecture characteristic adds complexity to the design. Thus, a critical job for architects lies in choosing the fewest architecture characteristics rather than the most possible. (link)
We prefer architecture characteristics because it describes concerns critical to the success of the architecture, and therefore the system as a whole, without discounting its importance. (link)
Vikram: [Other terms are 'Non-functional requirements', 'Quality attributes']
ArchiMate is a technical standard from The Open Group, and it offers a lighter-weight modeling language for enterprise ecosystems. The goal of ArchiMate is to be “as small as possible,” not to cover every edge case scenario. (link)
C4 is best suited for monolithic architectures where the container and component relationships may differ, and it’s less suited to distributed architectures, such as microservices. (link)
C4 is a diagramming technique developed by Simon Brown to address deficiencies in UML and modernize its approach. The four C’s in C4 are as follows: (link)
Yet, with all the writing and thinking about components and separation, developers and architects still struggle with achieving good outcomes (link)
Cohesion refers to what extent the parts of a module should be contained within the same module (link)
Fortunately, researchers created a variety of language-agnostic metrics to help architects understand modularity. We focus on three key concepts: cohesion, coupling, and connascence (link)
The basic topology of service-based architecture follows a distributed macro layered structure consisting of a separately deployed user interface, separately deployed remote coarse-grained services, and a monolithic database. (link)