Software engineering and GUI design Flexible layering DDD

Software engineering and. GUI design Flexible layering (DDD, CQRS) Event-driven Architecture, Event Sourcing http: //users. nik. uni-obuda. hu/prog 4/ 1

Martin Fowler Patterns • Patterns of Enterprise Application Architecture (2003/2004) • Refactoring (Improving the Design of Existing Code, 2018 2 nd ed) • https: //martinfowler. com/books/eaa. html 2

Contents 1. 1. Domain Logic Patterns ○ Transaction Script ○ Domain Model Today ○ Table Module ○ Service Layer Today 2. Data Source Architectural Patterns ORM ○ Table Data Gateway ○ Row Data Gateway ○ Active Record ○ Data Mapper 3. Object-Relational Behavioral Patterns ORM ○ Unit of Work ○ Identity Map ○ Lazy Load Prog 4 3

Contents 2. 4. Object-Relational Structural Patterns ORM ○ Identity Field ○ Foreign Key Mapping ○ Association Table Mapping ○ Dependent Mapping ○ Embedded Value ○ Serialized LOB ○ Single Table Inheritance ○ Class Table Inheritance ○ Concrete Table Inheritance ○ Inheritance Mappers 5. Object-Relational Metadata Mapping Patterns ○ Metadata Mapping Entity Framework ORM ○ Query Object Doctrine ORM ○ Repository Prog 3 4

Contents 3. 6. Web Presentation Patterns ○ Model View Controller Prog 4 ○ Page Controller ○ Front Controller ○ Template View Prog 4 ○ Transform View ○ Two Step View ○ Application Controller 7. Distribution Patterns ○ Remote Facade ○ Data Transfer Object Prog 4 8. Offline Concurrency Patterns ○ Optimistic Offline Lock Entity Framework ○ Pessimistic Offline Lock ○ Coarse-Grained Lock ○ Implicit Lock 5

Contents 4. 9. Session State patterns ASP. NET ○ Client Session State ○ Server Session State ○ Database Session State 10. Base Patterns ○ Gateway ○ Mapper ○ Layer Supertype ○ Separated Interface ○ Registry ○ Value Object ○ Money ○ Special Case ○ Plugin ○ Service Stub Prog 4 ○ Record Set 6

Layers – Prog 3 / Prog 4 7

Aim: Flexible layering • We don’t necessarily have to walk through all layers – Not necessarily the user is accessing the system – Automatic tests – API endpoints – Command-line scripts – Self-made and external automatic scripts • With these, we do not need the upper layers of the business logic, as each of them needs different upper layers Onion/Hexagon architecture • Some functions are required from all layers, they should not be bound to one single specific layer Logging, Messenger, Security … Cross cutting concerns / Aspect-oriented programming 8

Onion architecture 9

Hexagon architecture a ( dapters, ports…) 10

Cross cutting concerns (Aspects) 11

Alternative approach • With these approaches, the starting layer is defined by the ports/adapters, and some components can be layer-independent • This is where the traditional approaches give up • Martin Fowler, Vaughn Vernon, Eric Evans, Udi Dahan Domain Driven Design layering should not depend on the Web/UI/API access, but rather on the data operation that is executed 12

Domain Driven Design – Components 13

Domain Models • The DDD has management & organizational aspects too • Basic difference, that we DON’T start from the data model, we start from the business side • For this we need a common language („Ubiquitous Language”, „a model-based language to connect domain experts, developers, and the code itself ”), which we are skipping this semester • We focus on layering, first we have to find the separated Bounded Context s that will allow us to create the domain model – Simple Domain Model (Active Record), not the best approach – Rather: Rich Domain Model, the domain model doesn’t have to be tied to the database (that’s why it is good to have a Data Mapper / ORM that was presented in last semester) – Warning: Bloated domain objects (too much responsibilities) / Anemic domain objects (too few responsibilities), it is very hard to find the middle ground 14

DDD Rich Domain Model forget DRY 15

After the Domain Model • DDD goes along with the SOA keyword (Service-Oriented Architecture), today popular as „Microservices” • Martin Fowler is the big enthusiast in this topic • Module edge = service connection • This is truly language- and platform-independent • The Service Layer must act as a Facade: „It encapsulates the business logic, it DOES NOT define the business logic!” 16

Service Layer • It has to accept calls, and forward them towards the Domain Logic and the Application Logic – Domain Logic: Business logic operations – Application Logic (Workflow Logic): administrative responsibilities (email, scheduled tasks, upgrades, etc…) • The Service Layer can also be responsible for transactions/locks – Usually the lower layers also implement their own database transactions and thread synchronization too – In the Service Layer, we usually implement a type of the „Unit of Work” design pattern: „A Unit of Work keeps track of everything you do during a business transaction that can affect the database. When you're done, it figures out everything that needs to be done to alter the database as a result of your work. ” – Same strategy, only in the Microservice level 17

Saga • Another pattern can be mentioned on the Microservice level, with a different philosophy : Memento • Restore previous state on the subsystem/transaction level („Long -running transaction state tracker”) 18

Saga • Typically used when services might not get an instant reply (which happens really often, see Event Sourcing) • A transaction management implemented with long-running operations • Every activity must be capable of execution and rollback. The State. Tracker manages multiple activities, it handles success/failure, and the activity queue 19

Service Stub • In a Microservice environment it doesn’t matter whether a subsystem is local or remote • Services must be mocked the usual way (using interfaces) 20

Service Layer • Layers, Aspects, Services • The user interface itself must be a very thin layer performing API calls and displaying results 21

Service Layer the real DDD way! • To display a GUI, we use the database (or data services) to get data and display those to the user – The „Dashboard” and „Reports” functionalities are very common – Many times we gather data from multiple Bounded Context services this makes things slower – When reading data we shouldn’t need many operations that causes the whole service layer approach: validation, logging, etc. . • When we write data, we use the database (or data services) – Typically we only need one Bounded Context (actions that save data into multiple contexts are relatively rare) – We DO need the full functionality, because saving bad data means we will unable to work with the data, and correcting faulty data is very hard 22

DDD write / read 23

Solution: CQRS • Command-Query Responsibility Segregation (Martin Fowler) • Simplification of the Query side: we don’t need all layers 24

CQRS • Data gathered from multiple Bounded Context s can be faster – The user ALWAYS sees stale data – does it matter if the data is half second or 10 minutes or 2 days old? – We can use UI-specific, periodically refreshed storage that is independent of the individual Bounded Contexts User interface-specific tables (trend: denormalised/No. SQL data) 25

CQRS (Martin Fowler) 26

CQRS (Simple) 27

CQRS • Query problem: unique pages (typically search operations) ? – Optimisable using fulltext search methods (relational databases are getting better in this, but Elastic. Search is ranked #8 at db-engines. com/en/ranking) – Do we really have unique search? (auto*. fr: no, you don’t ) • Command problems – Failure is very rare, even then email notification is enough – Synchronized error reporting unnecessary, slows things down – By nature, it can be asynchronous (Event Sourcing!) – Immediate refresh of the View. Model storage can be slow, but only unavoidable in a few cases (e. g. price modification) 28

Event-driven Architecture • Very well suited for the asynchronous CQRS commands • Do we have to process commands immediately? Rarely – Many times, we need immediate reply: course registrations … – The importance of immediate replies depend on user and use case (we won’t be happy if we received an email 10 minutes later if the course registration was successful or not…) – With data modification commands, sometimes an immediate save is required, we have to identify these use cases – However, in many cases (order, application, comment, message, rating) it is absolutely no problem if the user sees „successful purchase”, and the real processing of the purchase is done 7 minutes later… – This is especially true, if we have many rarely failing transactions (For example: o*. uk) 29

Event-driven Architecture • Next to the resources, another advantage: flexibility • To do this, let’s see a simple example: how many phone numbers are there that start with a specified sequence? $ cat phone. Numbers. txt | grep ^079 | wc -l 3 • What to do, if we want to also display that TOTALLY how many phone numbers are in the database ? • In a classic program, this is a complex task: we have to change ALL layers • With event-driven architecture, only a small change is needed 30

Event-driven Architecture 3 phone numbers matched 31

Event-driven Architecture 3 of 15 phone numbers matched 32

Event sourcing 33

Event sourcing • The events are stored inside the Event Store database • The events are processed in a No. SQL / Queue database (Redis, Rabbit. MQ, MQTT/Hive. MQ), but the big Event Store can be a relational or non-relational database as well • Processing the events is not necessarily immediate! 34

Event sourcing 35

Event sourcing 36

CQRS (With event sourcing) 37

Event sourcing • Pros – Performance trail – Audit Trail – Simpler to integrate subsystems – The event store can be used to obtain more business data, multiple reports can be generated – Easier to search for bugs, and to test the system • Cons – Detailed aggregation/reporting is harder – Creating reports requires more technical and business knowledge – Feedback from a faulty request is not immediate – Bigger storage requirements – This is NOT a universally usable pattern !!! 38

Thank you for your attention ! Flexible layering (DDD, CQRS) Event-driven Architecture, Event Sourcing http: //users. nik. uni-obuda. hu/prog 4/ 39