Security News
Oracle Drags Its Feet in the JavaScript Trademark Dispute
Oracle seeks to dismiss fraud claims in the JavaScript trademark dispute, delaying the case and avoiding questions about its right to the name.
@node-ts/ddd
Advanced tools
Domain driven design (DDD) is an approach to software design that values simplicity and modeling code as closely to the business domain as possible. This results in code that can be easily understood by the business and evolved as the needs of the business domain change.
By isolating domain code away from all other concerns of the system like infrastructure, security, transportation, serialization etc; the complexity of the system grows only as large as the complexity of the business or problem domain itself.
If you are new to the concepts of DDD, it's highly recommended to do some background reading to grasp the motivations for this approach and to decide if it suits your application.
If you have already decided to use DDD for your application, this package is part of suite of purpose-built libraries that help you and your teams write large distributed node applications at enterprise scale and quality.
Install the @node-ts/ddd
package and its dependencies:
npm i @node-ts/ddd @node-ts/logger-core @node-ts/bus-messages inversify --save
The domain layer has no technical concerns like infrastructure, authentication, data access etc. The goal of the domain layer is to have a place in your application where code can be writen that models your business domains and rules in a way where those business complexities are kept separate from the rest of your application.
As a result, much of the code that gets written in this layer can be read by non-technical staff meaning that greater collaboration with the domain experts and validation of expected behaviours can be performed. Code here is easily unit testable and isolated from the rest of the application.
The domain layer is composed of one or more domains. Domains are logical boundaries around broad groups of related logic. Each domain is comprised of multiple aggregates, which are clusters of closely related data that model a single entity in the real world. Each aggregate has a root, that represents the single point of access into an aggregate and hosts all the actions that can be performed.
A simple example is a user of a website. In this example an "account" domain is established to encapsulate all aspects of user accounts, billing, profiles, contact details, etc. Users can perform the following actions:
register()
an accountchangePassword()
disable()
their accountWe can model that these actions have occured using bus Events
(see Bus Messages for more details). Here are the events for those actions:
// user-registered.ts
import { Event } from '@node-ts/bus-messages'
import { Uuid } from '@node-ts/ddd'
export class UserRegistered extends Event {
static readonly NAME = 'org/account/user-registered'
$name = UserRegistered.NAME
$version = 0
/**
* A user has registered with the website
* @param userId Identifies the user who registered
* @param email used to register the user
* @param isEnabled if the user can log in with this account
*/
constructor (
readonly userId: Uuid,
readonly email: string
readonly isEnabled: boolean
) {
}
}
// user-password-changed.ts
import { Event } from '@node-ts/bus-messages'
import { Uuid } from '@node-ts/ddd'
export class UserPasswordChanged extends Event {
static readonly NAME = 'org/account/user-password-changed'
$name = UserPasswordChanged.NAME
$version = 0
/**
* A user has changed their password
* @param userId Identifies the user who changed their password
* @param passwordChangedAt when the password was changed
*/
constructor (
readonly userId: Uuid,
readonly passwordChangedAt: Date
) {
}
}
// user-disabled.ts
import { Event } from '@node-ts/bus-messages'
import { Uuid } from '@node-ts/ddd'
export class UserDisabled extends Event {
static readonly NAME = 'org/account/user-disabled'
$name = UserDisabled.NAME
$version = 0
/**
* A user has disabled their account
* @param userId Identifies the user who changed their password
* @param isEnabled if the user can log in to their account
*/
constructor (
readonly userId: Uuid,
readonly isEnabled: boolean
) {
}
}
These events above are broadcasted to the rest of your system, normally with a message bus, each time one of the actions are performed on the aggregate root.
The following is an example implementation of the User
class:
// user.ts
import { AggregateRootProperties, AggregateRoot, Uuid } from '@node-ts/ddd'
import { UserRegistered, UserPasswordChanged, UserDisabled } from './events'
import { OAuthService } from './services'
export interface UserProperties extends AggregateRootProperties {
email: string
isEnabled: boolean
passwordChangedAt: Date | undefined
}
export class User extends AggregateRoot implements UserProperties {
email: string
isEnabled: boolean
passwordChangedAt: Date | undefined
// Creation static method. Aggregates are never "newed" up by consumers.
static register (id: Uuid, email: string): User {
const userRegistered = new UserRegistered(
id,
email,
true
)
const user = new User(id)
// event is applied to the user object
user.when(userRegistered)
return user
}
/**
* Changes the user's password that's used to log in to the site
* @param oauthService the oauth service that hosts the user account
* @param newPassword password the user wants to use
*/
async changePassword (oauthService: OAuthService, newPassword: string): Promise<void> {
// A domain service is used to perform the actual change of password
await oauthService.changePassword(this.id, newPassword)
const userPasswordChanged = new UserPasswordChanged(
this.id,
new Date()
)
super.when(userPasswordChanged)
}
/**
* Disable the user account so they can no longer log in
*/
disable (): void {
const userDisabled = new UserDisabled(this.id, false)
super.when(userDisabled)
}
protected whenUserRegistered (event: UserRegistered): void {
this.email = event.email
this.isEnabled = event.isEnabled
}
protected whenPasswordChanged (event: UserPasswordChanged): void {
this.passwordChangedAt = event.passwordChangedAt
}
protected whenUserDisabled (event: UserDisabled): void {
this.isEnabled = event.isEnabled
}
}
This approach to modeling the business domain is well documented in DDD spheres. It's clear what actions a user can perform, what the business rules are those actions, and what data updates as a result. Furthermore because all changes to the data is represented in events that are broadcasted, these can be collected and stored to form a full audit log and history of all changes to your system.
// user-write-repository.ts
import { injectable, inject } from 'inversify'
import { Connection } from 'typeorm'
import { LOGGER_SYMBOLS, Logger } from '@node-ts/logger-core'
@injectable()
export class UserWriteRepository extends WriteRepository<User, UserWriteModel> {
constructor (
@inject(SHARED_SYMBOLS.DatabaseConnection) databaseConnection: Connection,
@inject(LOGGER_SYMBOLS.Logger) logger: Logger
) {
super(User, UserWriteModel, databaseConnection, logger)
}
}
// user-service.ts
import { injectable, inject } from 'inversify'
import { OAuthService } from './services'
import { RegisterUser, ChangePasswordForUser, DisableUser } from './commands'
@injectable()
export class UserService {
constructor (
@inject(ACCOUNT_SYMBOLS.UserWriteRepository)
private readonly userWriteRepository: UserWriteRepository,
@inject(ACCOUNT_SYMBOLS.OAuthService)
private readonly oauthService: OAuthService
) {
}
async register ({ id, email }: RegisterUser): Promise<void> {
const user = User.register(id, email)
await this.userWriteRepository.save(user)
}
async changePassword ({ id, newPassword }: ChangePasswordForUser): Promise<void> {
const user = await this.userWriteRepository.getById(id)
await user.changePassword(this.oauthService, newPassword)
await this.userWriteRepository.save(user)
}
async disable ({ id }: DisableUser): Promise<void> {
const user = await this.userWriteRepository.getById(id)
await user.disable()
await this.userWriteRepository.save(user)
}
}
FAQs
A domain driven design framework for enterprise grade applications
The npm package @node-ts/ddd receives a total of 2 weekly downloads. As such, @node-ts/ddd popularity was classified as not popular.
We found that @node-ts/ddd demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Oracle seeks to dismiss fraud claims in the JavaScript trademark dispute, delaying the case and avoiding questions about its right to the name.
Security News
The Linux Foundation is warning open source developers that compliance with global sanctions is mandatory, highlighting legal risks and restrictions on contributions.
Security News
Maven Central now validates Sigstore signatures, making it easier for developers to verify the provenance of Java packages.