Enterprise Software Development Patterns
Download as PPTX, PDF0 likes532 views
This document discusses several enterprise software patterns including bounded contexts, command query responsibility segregation (CQRS), domain events, event sourcing, asynchronous messaging, non-relational data storage, performance versus scalability, and scale-up versus scale-out. It provides definitions and examples of how these patterns address challenges with complex enterprise applications and domains by decomposing models, separating reads from writes, using events to communicate changes, and leveraging asynchronous and distributed architectures.
Enterprise Software Development Patterns
- 1. Enterprise Software Patterns Josh Lane - Wintellect
- 2. Why Enterprise Patterns? • Techniques for simple apps don’t always scale to complex ones • CRUD • Synchronous communication • Unified entity definitions • Expected lifetime and complexity of a large-scale application requires formal choices • Tradeoff is more “big picture” complexity for relatively less “local” complexity • Another big goal is the ability to gracefully evolve over time
- 3. Bounded Context • Formal decomposition of a complex domain model into simpler sub- models • Characteristics • Different bounded contexts can have formal relationships (Domain Events, etc.) • The same domain entity will appear in multiple bounded contexts, with only those properties and behaviors useful within that context • Boundaries are typically defined in terms of human concepts • Most appropriate for complex domains • If entity classes start to become large, with subsets of related properties/methods, this usually indicates that BCs are needed • Drawbacks • Complex – formal interactions via events can be hard to grasp, vs. database schema • Confusing – multiple entity class definitions can seem “weird”
- 5. Command-Query Responsibility Segregation (CQRS) • Formal separation of data writes (“commands”) vs. data reads (“queries”) • Main alternative is classic CRUD • Why? • Easier to accommodate many more reads vs. writes (or vice versa) • Easier to accommodate different read vs. write semantics (aggregate reads but discrete writes, multiple read styles, etc.) • Often used with Event Sourcing, Bounded Contexts • Main drawback is that its more complex than CRUD
- 8. Domain Events • Formal modeling of relevant happenings within a problem domain • Like UI-style events (“button1 clicked”, etc.) but for the domain model itself • “new user added to the system” • “new drilling plan started” • “private workspace data promoted to a public workspace” • Uses • Communication within and between Bounded Contexts • Communication with external systems • Used to implement Event Sourcing • Requires a pub/sub messaging architecture like a service bus • Typical alternative is data-level (foreign keys, etc.) • More complex than FKs, but much more flexible • Can result in temporary out-of-sync issues • There are formal patterns to deal with this (Eventual Consistency, etc.)
- 10. Event Sourcing • Store all changes within an application domain as a sequence of events • Enables event-based query, point-in-time reconstruction of state, etc. • A natural fit with Domain Events • Can be used to implement an audit log • Log entries may not line up perfectly with event stream elements… might require some translation • Requires durable storage, occasional pruning of the persisted event stream, etc.
- 12. Asynchronous Messaging • Shift away from traditional RPC-style request/response pattern • Async patterns • Pub/sub (one-to-many, event-based broadcast) • One-way unicast (“commands”) • Two-way unicast (“messages”) • Allows loosely-coupled senders and receivers • Agree only on message semantics • Allows for independent resource allocation • Provides “shock absorber” for handling traffic spikes, transient node failures, etc. • Implications • Sender – doesn’t wait for response, may affect user experience • Receiver – may require some means to communicate back to sender • Can be implemented via queues, service bus, database, etc.
- 13. Non-Relational Data Storage (“NoSQL”) • Purposeful use of denormalized and/or pre-aggregated data • Requires careful consideration of intended data access patterns • Trades off improved performance and scalability for reduced ad-hoc query capability • Relational model has inherent limits to scalability • In NoSQL, database modeling is less important and software modeling is more important • Often most effective when used with other types of storage (blob, relational, etc.)… “Polyglot Persistence” • Works in conjunction with Bound Context, Domain Events, CQRS, etc.
- 14. Performance vs. Scalability • Related, but not the same thing • Performance seconds/request • Scalability requests/second • Performance • In a typical enterprise system, performance is a user-centric definition • For each major system function, define a minimally acceptable time threshold • A software system has good performance to the extent that it performs each major function in its minimally acceptable time, for one user • Defining performance with raw statistics and no context is meaningless (“the system is fast, we can do 1000 writes/second”, etc.) • Performance is a measurement of meeting these minimum time thresholds… “the system is 38% performant”, etc. • Scalability • In a typical enterprise system, scalability is a cost-centric definition • A software system has good scalability to the extent that it minimizes the cost to achieve performance (defined above) as the number of users increases over time • Scalability is a measure of time and effort (in other words, cost)… “the system is highly scalable, to support 2x users we don’t need to change code, we just add two more servers and change one config file”, etc. • Remember! Code is expensive, hardware is cheaper, configuration is cheapest
- 15. Scale-up vs. Scale-out • Two patterns for scaling an enterprise application • Scale-up – replace existing hardware with bigger, faster hardware; deceptively easy • Scale-out – augment existing hardware with more nodes in the cluster; uses cheap commodity hardware; public cloud is built on this model • Requirements • Scale-up – ability to make large-scale investments • Scale-out – explicit architecture and design (stateless, loosely-coupled middle tier, etc.) • Limitations • Scale-up – budget, SLAs, hardware, data layer • Scale-out – often not compatible with legacy software