This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Bounded Context
Bounded Context

Version management

Difference between version and

At line 1 added 37 lines
!!! Overview [1]
[{$pagename}] is the boundary or perimeter of a [context]
Various [entities] (usually [persons]) draw boundaries between [contexts]. You also find multiple [contexts] within the same [domain] [context], such as the separation between [data In Process] and [Database Management System] models within in a single [application]. This boundary is set by the different way we represent [models|Architecture].
[{$pagename}] is a central pattern in [Domain-Driven Design].
[{$pagename}] is a [context] encapsulated by a set of responsibilities and definitions.
!! Building blocks of DDD[2]
In the book [Domain-Driven Design], a number of high-level concepts and practices are articulated, such as ubiquitous language meaning that the domain model should form a common language given by domain experts for describing system requirements, that works equally well for the business users or sponsors and for the software developers. The book is very focused on describing the domain layer as one of the common layers in an object-oriented system with a multilayered architecture. In [Domain-Driven Design], there are artifacts to express, create, and retrieve [domain] models:
* [Entity]
* [Value Object]
* [Aggregate]
* [Service]
* [Repository]
* [Factory]
!! Examples of [{$pagename}]
A customer comes to a [website] and places an order. The order is entered within the order system and flows to Order Processing where the payment information is processed and then from there to the Shipping department.
Many organizations would view the ordering process as a single process and create a single [monolithic application|Monolithic Architecture] that would process the entire Order.
[Internet] Scale requires a different approach.
The customer's [password] is not needed by the shipping department. The information required for the Order Processing is not necessarily the same information required to ship the Order. Certainly the Shipping department does not require access to the [Payment Card] information which may even be processed by a [Third-party].
!! [{$pagename}] and [Monolithic Architectures]
[{$pagename}] has been used in [Monolithic Architectures] for several years where different [Software] [Components] [Functions] use [Inter-Process Communication] for passing [Messages]
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [BoundedContext|http://martinfowler.com/bliki/BoundedContext.html|target='_blank'] - based on 2015-05-18
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop